[Rd] gfortran Makefile for windows
Hi all,
(Originally posted to r-help)
I'm porting a package that I've worked on for OS X to Windows.
The package is written in F95 so I need to compile it with gfortran
and link it with gcc4.
I've been trying to build an R with gcc4 without luck so far. If there is
a binary of such a thing info would be appreciated.
This package requires a Makefile. My question is, how can I find out
(or what is), the link command?
Here is the OS X Makefile:
RLIB_LOC=${R_HOME}
F90_FILES=\
class_data_frame.f90 \
class_old_dbest.f90 \
class_cm_data.f90 \
class_cm.f90 \
class_bgw.f90 \
class_cm_mle.f90 \
cme.f90
FORTRAN_FILES=\
dgletc.f \
dglfgb.f\
dglfg.f\
dmdc.f\
mecdf.f
%.o: %.f90
gfortran -c -g $<
%.o: %.f
gfortran -c -g $<
bpkg.so: $(F90_FILES:%.f90=%.o) $(FORTRAN_FILES:%.f=%.o)
gcc -Wall -bundle -flat_namespace -undefined suppress -L/sw/lib
-L/usr/local/lib -o $@ $^ \
-L$(RLIB_LOC)/lib -lR
###EOF
The -L lib dirs are not correct. On a *nix platform I would do something
like this
sh -x R CMD SHLIB ...
to get at the R internal link information but I can't get that to work on
Cygwin.
Regards,
Joel
--
Joel Bremson
Graduate Student
Institute for Transportation Studies - UC Davis
http://etrans.blogspot.com
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] gfortran Makefile for windows
I am unaware that gfortran or gcc4 exist as a MinGW binary for Windows.
You mention Cygwin, but that is not a supported platform for R.
There is a g95 binary for Windows.
You can find how to link on Windows from the sources: most of the rules
are in src/gnuwin32/MkRules. I suspect all you need is to set
pkgname-DLLLIBS appropriately.
I don't see that you need a Makefile: a Makevars file would suffice and
avoid your hardcoding so many OS-specific features. In any case it seems
to me that in general you need to link against the Fortran libraries: you
may get away with it on MacOS, but you will not on Windows.
Support for F95 files is planned for R 2.3.0, but depends on being able to
differentiate F77 and F95 sources where needed (most platforms).
Meanwhile we will try to add an example to the R-admin manual for 2.2.0.
On Wed, 28 Sep 2005, Joel Bremson wrote:
> Hi all,
>
> (Originally posted to r-help)
Congratulations: you have now read the posting guide and selected an
appropriate list! Perhaps soon you will get the part about not sending
HTML mail?
Seriously, there is a posting guide, and it asks you to do your homework
before posting. Please show us the courtesy of doing so.
> I'm porting a package that I've worked on for OS X to Windows.
> The package is written in F95 so I need to compile it with gfortran
> and link it with gcc4.
>
> I've been trying to build an R with gcc4 without luck so far. If there is
> a binary of such a thing info would be appreciated.
>
> This package requires a Makefile. My question is, how can I find out
> (or what is), the link command?
>
> Here is the OS X Makefile:
>
>
> RLIB_LOC=${R_HOME}
>
> F90_FILES=\
> class_data_frame.f90 \
> class_old_dbest.f90 \
> class_cm_data.f90 \
> class_cm.f90 \
> class_bgw.f90 \
> class_cm_mle.f90 \
> cme.f90
>
>
> FORTRAN_FILES=\
> dgletc.f \
> dglfgb.f\
> dglfg.f\
> dmdc.f\
> mecdf.f
>
>
> %.o: %.f90
> gfortran -c -g $<
>
> %.o: %.f
> gfortran -c -g $<
>
> bpkg.so: $(F90_FILES:%.f90=%.o) $(FORTRAN_FILES:%.f=%.o)
> gcc -Wall -bundle -flat_namespace -undefined suppress -L/sw/lib
> -L/usr/local/lib -o $@ $^ \
> -L$(RLIB_LOC)/lib -lR
>
> ###EOF
>
> The -L lib dirs are not correct. On a *nix platform I would do something
> like this
>
> sh -x R CMD SHLIB ...
>
> to get at the R internal link information but I can't get that to work on
> Cygwin.
>
> Regards,
>
> Joel
>
> --
> Joel Bremson
> Graduate Student
> Institute for Transportation Studies - UC Davis
> http://etrans.blogspot.com
>
> [[alternative HTML version deleted]]
--
Brian D. Ripley, [EMAIL PROTECTED]
Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel: +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UKFax: +44 1865 272595
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Future plans for raw data type?
On Tue, 27 Sep 2005 [EMAIL PROTECTED] wrote:
> I've been working with raw vectors quite a bit and was wondering if
> the R team might comment on where they see raw vector support going in
> the long run. Is the intent that 'raw' will eventually become a first
> class data type on the same level as 'integer'? Or should 'raw' have
> more limited support, by design?
They _are_ `first class data types', atomic vectors, just like integers.
The intent remains that their contents should not be interpreted, just as
in the Green Book. One comsequential difference from other atomic vectors
is that there is no notion of NA for raw elements.
This means that there are basically no plans to add support for
manipulation of raw vectors. We have already gone quite a lot further
than S does, and quite a few things have been considered undesirable (see
below).
> For example, with very minor changes to subassign.c to implement some
> automatic coercions, raw vectors can become arguments to ifelse() and
> can be members of data frames. Would this be desirable?
It is desirable that they can be members of data frames, which is why they
_can_ be:
> y <- charToRaw("test")
> z <- data.frame(y)
format() was not handling raw until recently, but now does. Thus z can
now be printed. (Again, it is somewhat dubious that one should be able to
format/print raw vectors as that imposes an interpretation, but it is
convenient.)
ifelse() is coded in a peculiar way that needs logical to be coercible
(for some values of 'test') to a common mode for 'yes' and 'no'.
Alternatives are given on its help page.
Given that you cannot interpret raw elements, you cannot unambiguously
coerce logical to raw. In particular there is no way to coerce logical NA
to raw. So what should ifelse(NA, yes, no) be? There is no good answer,
which is why the status quo is desirable. (as.raw warns if you attempt
this.)
You are vague as to which `automatic coercions' you think could be added,
but at least this one was deliberately not added.
Digging around I did find one unanticipated problem. If z is a list z$a
<- raw_vector works but z[["a"]] <- raw_vector does not. The reason is
that for atomic vectors the latter first coerces the rhs to a list and
then extracts the first element. Which is clearly wasteful (and not
documented), and I will take a closer look at it for 2.3.0, but I've added
sticking plaster for 2.2.0.
--
Brian D. Ripley, [EMAIL PROTECTED]
Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel: +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UKFax: +44 1865 272595
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] gfortran Makefile for windows
On Wed, 28 Sep 2005, Prof Brian Ripley wrote:
> I am unaware that gfortran or gcc4 exist as a MinGW binary for Windows.
> You mention Cygwin, but that is not a supported platform for R.
>
> There is a g95 binary for Windows.
At www.g95.org, but I found no installation instructions relevant to
Windows. Some comments at the end of this message.
[...]
> Support for F95 files is planned for R 2.3.0, but depends on being able to
> differentiate F77 and F95 sources where needed (most platforms).
> Meanwhile we will try to add an example to the R-admin manual for 2.2.0.
Here is an example src/Makefile.win for a package called testf95 that uses
F95/F90 only.
% cat testf95/src/Makefile.win
DLLNAME=testf95 # will not be needed in 2.2.0
include $(RHOME)/src/gnuwin32/MkRules
F90SOURCES=$(wildcard -f *.f90)
F95SOURCES=$(wildcard -f *.f95)
OBJS=$(F90SOURCES:.f90=.o) $(F95SOURCES:.f95=.o)
G95=c:/packages/g95/bin/g95
MINGW=c:/packages/gcc-3.4.4/
.SUFFIXES: .f90 .f95
.f90.o:
$(G95) -c $< -o $@
.f95.o:
$(G95) -c $< -o $@
## at least on my setup, G95 is not searching MinGW libs.
DLL=$(G95) -L$(MINGW)/lib
all: $(DLLNAME).dll
## Rules copied from MakeDll
RCNAME=${DLLNAME}_res
RCOBJ=$(RCNAME).o
RESFLAGS=--include-dir $(RHOME)/include
$(DLLNAME)_res.rc:
@PERL5LIB=$(RHOME)/share/perl perl
$(RHOME)/src/gnuwin32/makeDllRes.pl $(DLLNAME) > $@
$(DLLNAME)_res.o: $(DLLNAME)_res.rc $(RHOME)/include/Rversion.h
$(DLLNAME).a: $(OBJS)
$(DLLNAME).dll : $(DLLNAME).a $(RCOBJ)
It works for me, but do be aware that it will depend on the
fine details of how your MinGW/G95 tools are installed. I had to copy
dllcrt2.o from MINGW/lib to
C:/packages/g95/lib/gcc-lib/i686-pc-mingw32/4.0.1 since the paths are
processed after that file. It is probably better to fiddle with the specs
file.
--
Brian D. Ripley, [EMAIL PROTECTED]
Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel: +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UKFax: +44 1865 272595
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] looks in liblapack.a not liblapack.so
Peter Dalgaard wrote:
> Hmm. Doesn't look like it is actually working, though. Install
> lapack-devel, configure --with-lapack, and make check dies with
>
> running code in 'base-Ex.R' ...make[4]: *** [base-Ex.Rout] Error 1
> make[4]: Leaving directory `/home/pd/r-devel/BUILD/tests/Examples'
> make[3]: *** [test-Examples-Base] Error 2
>
> [EMAIL PROTECTED] BUILD]$ tail tests/Examples/base-Ex.Rout.fail
>> kappa(x2 <- cbind(x1,2:11))# high! [x2 is singular!]
> [1] 8.351867e+16
>>
>> hilbert <- function(n) { i <- 1:n; 1 / outer(i - 1, i, "+") }
>> sv9 <- svd(h9 <- hilbert(9))$ d
>> kappa(h9)# pretty high!
> [1] 728289254735
>> kappa(h9, exact = TRUE) == max(sv9) / min(sv9)
> Error in La.svd(x, nu, nv) : BLAS/LAPACK routine 'DGEBRD' gave error code
> -10 Execution halted
>
> This happens on both x86_64 and x86 installs of FC4.
I am sorry Peter, I am trying really hard to replicate this bug but I have
not been able to see the same result, no matter what I try.
I have download the latest tar ball and then I run:
$ ./configure --with-lapack="-llapack -lblas"
...
R is now configured for x86_64-unknown-linux-gnu
Source directory: .
Installation directory:/usr/local
C compiler:gcc -g -O2
C++ compiler: g++ -g -O2
Fortran compiler: gfortran -g -O2
Interfaces supported: X11
External libraries:readline
Additional capabilities: PNG, JPEG, iconv, MBCS, NLS
Options enabled: R profiling
Recommended packages: yes
$ make -j8
$ make check
It works.
OTOH I am not sure that configure is accepting my options. Looking into
config.log I don't see that value being used, and I noticed that the lapack
module it is still being built.
I read docs/manual/R-admin.html but without any difference. I have tried
different forms:
--with-lapack
--with-lapack="-llapack -lcblas"
--with-lapack="-llapack -lblas"
What am I missing?
> I have a strong sense of deja vu regarding this error.
Thanks,
--
José Abílio
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] looks in liblapack.a not liblapack.so
José Matos <[EMAIL PROTECTED]> writes:
> Peter Dalgaard wrote:
>
> > Hmm. Doesn't look like it is actually working, though. Install
> > lapack-devel, configure --with-lapack, and make check dies with
> >
> > running code in 'base-Ex.R' ...make[4]: *** [base-Ex.Rout] Error 1
> > make[4]: Leaving directory `/home/pd/r-devel/BUILD/tests/Examples'
> > make[3]: *** [test-Examples-Base] Error 2
> >
> > [EMAIL PROTECTED] BUILD]$ tail tests/Examples/base-Ex.Rout.fail
> >> kappa(x2 <- cbind(x1,2:11))# high! [x2 is singular!]
> > [1] 8.351867e+16
> >>
> >> hilbert <- function(n) { i <- 1:n; 1 / outer(i - 1, i, "+") }
> >> sv9 <- svd(h9 <- hilbert(9))$ d
> >> kappa(h9)# pretty high!
> > [1] 728289254735
> >> kappa(h9, exact = TRUE) == max(sv9) / min(sv9)
> > Error in La.svd(x, nu, nv) : BLAS/LAPACK routine 'DGEBRD' gave error code
> > -10 Execution halted
> >
> > This happens on both x86_64 and x86 installs of FC4.
>
> I am sorry Peter, I am trying really hard to replicate this bug but I have
> not been able to see the same result, no matter what I try.
>
> I have download the latest tar ball and then I run:
>
> $ ./configure --with-lapack="-llapack -lblas"
> ...
> R is now configured for x86_64-unknown-linux-gnu
>
> Source directory: .
> Installation directory:/usr/local
>
> C compiler:gcc -g -O2
> C++ compiler: g++ -g -O2
> Fortran compiler: gfortran -g -O2
>
> Interfaces supported: X11
> External libraries:readline
> Additional capabilities: PNG, JPEG, iconv, MBCS, NLS
> Options enabled: R profiling
>
> Recommended packages: yes
>
> $ make -j8
> $ make check
>
> It works.
>
> OTOH I am not sure that configure is accepting my options. Looking into
> config.log I don't see that value being used, and I noticed that the lapack
> module it is still being built.
>
> I read docs/manual/R-admin.html but without any difference. I have tried
> different forms:
>
> --with-lapack
> --with-lapack="-llapack -lcblas"
> --with-lapack="-llapack -lblas"
>
> What am I missing?
-L/usr/lib64 I think. I have
#LAPACK_LIBS="-L/usr/lib64 -llapack"
(commented out now) in config.site.
../R/configure --with-lapack="-L/usr/lib64 -llapack"
seems to work with FC4/Opteron (even with the configure line, you
still need to have at least "--with-lapack" on the command line, which
is a bit of a bug -- or will be one, once we stop advising against
using external lapack libs in the first place...).
A line like
External libraries:readline, BLAS(ATLAS), LAPACK(generic)
shows that R is not using the internal versions of BLAS/LAPACK. (Of
course, the ATLAS bit required more work...)
The latest updates to lapack seem not to have worked.
> > I have a strong sense of deja vu regarding this error.
>
> Thanks,
> --
> José AbÃlio
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
--
O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B
c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K
(*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918
~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Future plans for raw data type?
On Wed, Sep 28, 2005 at 10:59:39AM +0100, Prof Brian Ripley wrote:
>
> They _are_ `first class data types', atomic vectors, just like integers.
> The intent remains that their contents should not be interpreted, just as
> in the Green Book. One comsequential difference from other atomic vectors
> is that there is no notion of NA for raw elements.
That's reasonable. I should have known to be more specific in saying
what I meant by "first class data type", but drawing the line at
interpreting the contents of a raw seems fine.
> It is desirable that they can be members of data frames, which is why they
> _can_ be:
>
> >y <- charToRaw("test")
> >z <- data.frame(y)
Hmmm, that's interesting; I wonder how I missed the fact that this
worked. Somehow I managed to only try things that didn't, even though
the obvious case does work. Here are some things that are broken:
x <- data.frame(a=1:10)
x$b <- as.raw(1:10)
x[[2]] <- as.raw(1:10)
x <- data.frame(as.raw(1:10))
x[1,]
x[1,1]
> Given that you cannot interpret raw elements, you cannot unambiguously
> coerce logical to raw. In particular there is no way to coerce logical NA
> to raw. So what should ifelse(NA, yes, no) be? There is no good answer,
> which is why the status quo is desirable. (as.raw warns if you attempt
> this.)
>
> You are vague as to which `automatic coercions' you think could be added,
> but at least this one was deliberately not added.
Because of how ifelse() is implemented, for type 'X', it requires both
'X' <- logical and logical <- 'X' coercions. The 'X' <- logical
coercion is used for handling NA elements in 'test' even if there are
none. The logical <- 'X' coercion is required due to how ifelse()
constructs the result vector from 'yes' and 'no'. The logical <- raw
coercion seems unambiguous. Arguably, ifelse() should not care about
the ability to represent NA if there are no NA values in 'test', and
could do:
if (any(nas)) ans[nas] <- NA
instead of:
ans[nas] <- NA
I think this is a little bit more consistent with how ifelse() handles
the 'yes' and 'no' arguments, as well (they are only evaluated if they
are actually used). But as you say, ifelse() is pretty easily to work
around.
> Digging around I did find one unanticipated problem. If z is a list z$a
> <- raw_vector works but z[["a"]] <- raw_vector does not. The reason is
> that for atomic vectors the latter first coerces the rhs to a list and
> then extracts the first element. Which is clearly wasteful (and not
> documented), and I will take a closer look at it for 2.3.0, but I've added
> sticking plaster for 2.2.0.
I think this is related to the problems I described above, and I
suspect that your fix is the same as mine (i.e. handle "case 1924" in
subassign.c).
-- Dave
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] looks in liblapack.a not liblapack.so
Peter Dalgaard wrote: > -L/usr/lib64 I think. I have > > #LAPACK_LIBS="-L/usr/lib64 -llapack" > > (commented out now) in config.site. I'm sorry, it was my mistake. I forgot to install blas-devel where libblas.so is defined as a symbolic link to the correct library version. Since the configure script could not find the blas library it would immediately disallow the lapack usage. This is not obvious from configure's output... maybe an explicit message saying this would help here. So now it is enough ../R/configure --with-lapack :-) > ../R/configure --with-lapack="-L/usr/lib64 -llapack" > > seems to work with FC4/Opteron (even with the configure line, you > still need to have at least "--with-lapack" on the command line, which > is a bit of a bug -- or will be one, once we stop advising against > using external lapack libs in the first place...). > > A line like > > External libraries:readline, BLAS(ATLAS), LAPACK(generic) Yes, I get this. For now I have BLAS(generic). > shows that R is not using the internal versions of BLAS/LAPACK. (Of > course, the ATLAS bit required more work...) > > The latest updates to lapack seem not to have worked. You are right, I am able to reproduce the bug. I will report it and report back when a solution is available. > >O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B > c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K > (*) \(*) -- University of Copenhagen Denmark Ph: (+45) > 35327918 > ~~ - ([EMAIL PROTECTED]) FAX: (+45) > 35327907 > Thanks, -- José Abílio __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] looks in liblapack.a not liblapack.so
On Thu, 2005-09-22 at 10:36 +0100, Prof Brian Ripley wrote: > Probably because it is discussed in the R-admin manual as having > previously appeared in Debian and being traced to an erroneous patch to > the Lapack 3.0 sources. You wouldn't happen to have more specific details on this, would you? :) I know there is a fair amount of cruft in the Fedora lapack package, and I'd like to clean it out, but I want to make sure I don't remove any legitimate bug-fixes in the process. (See: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=169399 for some semi-related discussion of lapack and its patching) Thanks, ~spot -- Tom "spot" Callaway: Red Hat Senior Sales Engineer || GPG ID: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Summary of translation status
Dear R-devel & Translation Teams, In order to monitor the progress of the translation for the pt_BR team I wrote a script to summarize the status of the translations. It wasn't difficult to extend it to the other languages so I decided to set up a page with the summaries of the translation for all languages for which currently exist a translation. http://www.ime.usp.br/~feferraz/en/rtransstat.html If any of you find it useful I can keep it updated on a regular basis (daily or weekly). Thank you, (PS: I'm resending this message because it didn't get through the filter the first time. Sorry for the inconvenience for those that are receiving it more than one time). -- Fernando Henrique Ferraz P. da Rosa http://www.feferraz.net __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Summary of translation status
Could you enlarge this to include translations of the help files and documentation too so there is a single location that one can refer to? If this is already tracked somewhere else then just a link at the top would be enough. On 9/28/05, Fernando Henrique Ferraz P. da Rosa <[EMAIL PROTECTED]> wrote: >Dear R-devel & Translation Teams, > >In order to monitor the progress of the translation for the > pt_BR team I wrote a script to summarize the status of the translations. > It wasn't difficult to extend it to the other languages so I decided to > set up a page with the summaries of the translation for all languages > for which currently exist a translation. > >http://www.ime.usp.br/~feferraz/en/rtransstat.html > >If any of you find it useful I can keep it updated on a regular basis > (daily or weekly). > > >Thank you, > > > (PS: I'm resending this message because it didn't get through the > filter the first time. Sorry for the inconvenience for those that > are receiving it more than one time). > > -- > Fernando Henrique Ferraz P. da Rosa > http://www.feferraz.net > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Summary of translation status
Gabor Grothendieck writes: > Could you enlarge this to include translations of the help files > and documentation too so there is a single location that one > can refer to? If this is already tracked somewhere else then > just a link at the top would be enough. > As far as I know this kind of information is not centralized, as today there exists no standard procedure for providing translated versions of the help files and documentation (as exists for the message files, at least). We have the contributed documentation page: http://cran.r-project.org/other-docs.html , where links can be found to (some of the) translated documentation available. As far as the help files go I never read or heard anything about. Is there any effort going on to translate them? The idea to have a single location to refer to when it comes to the translation efforts sounds good though. We just have to consider a way to centralize information on the translation of documentation and help files. -- Fernando Henrique Ferraz P. da Rosa http://www.feferraz.net __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
