compiling R devel on vanilla tiger

Hi

I am trying to compile R-devel (the version from yesterday) with a
"vanilla" installation of Tiger on a new Powerbook. Vanilla means I
am running
   - Xcode 2.1
   - Gcc 4.0
   - The gfortran build which Simon Urbanek has on his wiki website
(build number 5202)
   - make version "GNU Make 3.80 "
   - libtool version "Apple Computer, Inc. version cctools-590"
   - autoconf version "autoconf (GNU Autoconf) 2.59 "

I do ./configure with the options
    ./configure F77=gfortran FLIBS=/usr/lib/libgfortran.a --with-
blas='-framework vecLib'
     --with-lapack R_PAPERSIZE=letter --with-aqua

(btw are these the "right" options?), which gives my the configure
output:

R is now configured for powerpc-apple-darwin8.2.0

   Source directory:          .
   Installation directory:    /Library/Frameworks

   C compiler:                gcc  -g -O2
   C++ compiler:              g++  -g -O2
   Fortran compiler:          gfortran  -g -O2

   Interfaces supported:      X11, aqua, tcltk
   External libraries:        readline
   Additional capabilities:   iconv, MBCS, NLS
   Options enabled:           framework, R profiling

   Recommended packages:      yes

Making yields the error reproduced below.

How do I fix this? Shoudl I switch fortran compiler? Or install
another version of libtool? Or?

Kasper


Make error:

gcc -dynamiclib -L/usr/local/lib -install_name /Library/Frameworks/
R.framework/Versions/2.2.0/Resources/lib/libRlapack.dylib -o
libRlapack.dylib dlamc.lo dlapack0.lo dlapack1.lo dlapack2.lo
dlapack3.lo cmplx.lo  cmplxblas.lo  /usr/lib/libgfortran.a
ld: Undefined symbols:
_dasum_
_daxpy_
_dcopy_
_ddot_
_dgemm_
_dgemv_
_dger_
_dnrm2_
_drot_
_dscal_
_dswap_
_dsymv_
_dsyrk_
_dtbsv_
_dtpsv_
_dtrmm_
_dtrmv_
_dtrsv_
_idamax_
_xerbla_
_dtpmv_
_dtrsm_
_dgbmv_
_dsbmv_
_dspmv_
_dspr2_
_dspr_
_dsymm_
_dsyr2_
_dsyr2k_
_dsyr_
_dtbmv_
_zgemm_
/usr/bin/libtool: internal link edit command failed
make[4]: *** [libRlapack.dylib] Error 1
make[3]: *** [R] Error 2
make[2]: *** [R] Error 1
make[1]: *** [R] Error 1
make: *** [R] Error 1

"Jan" == Jan de Leeuw <deleeuw at stat.ucla.edu>
    on Fri, 19 Aug 2005 11:41:19 -0700 writes:

"Jan" == Jan de Leeuw <deleeuw at stat.ucla.edu>
    on Fri, 19 Aug 2005 11:41:19 -0700 writes:

    Jan> The current R-devel version forgets to add "-framework
    Jan> vecLib" when linking libLapack.dylib. Go to
    Jan> src/modules/lapack, run make, then paste the failing
    Jan> link statement into terminal and add "-framework
    Jan> vecLib" to the end of it. Then go back to the top level
    Jan> and run make to finish the whole thing.

This may be fixable by changing
   <Rsource>/configure.ac   which produces  <Rsource>/configure
which later produces
   <Rbuild>/etc/Makeconf

Can you find out at least what changes are needed to etc/Makeconf
and forward your information to the R-devel mailing list ?

Thank you in advance,
Martin

    Jan> On Aug 19, 2005, at 11:35 , Kasper Daniel Hansen wrote:

Hi

I am trying to compile R-devel (the version from
yesterday) with a "vanilla" installation of Tiger on a
new Powerbook. Vanilla means I am running - Xcode 2.1 -
Gcc 4.0 - The gfortran build which Simon Urbanek has on
his wiki website (build number 5202) - make version "GNU
Make 3.80 " - libtool version "Apple Computer,
Inc. version cctools-590" - autoconf version "autoconf
(GNU Autoconf) 2.59 "

I do ./configure with the options ./configure
F77=gfortran FLIBS=/usr/lib/libgfortran.a --with-
blas='-framework vecLib' --with-lapack R_PAPERSIZE=letter
--with-aqua

(btw are these the "right" options?), which gives my the
configure output:

R is now configured for powerpc-apple-darwin8.2.0

Source directory: .  Installation directory:
/Library/Frameworks

C compiler: gcc -g -O2 C++ compiler: g++ -g -O2 Fortran
compiler: gfortran -g -O2

Interfaces supported: X11, aqua, tcltk External
libraries: readline Additional capabilities: iconv, MBCS,
NLS Options enabled: framework, R profiling

Recommended packages: yes

Making yields the error reproduced below.

How do I fix this? Shoudl I switch fortran compiler? Or
install another version of libtool? Or?

Kasper


Make error:

gcc -dynamiclib -L/usr/local/lib -install_name
/Library/Frameworks/
R.framework/Versions/2.2.0/Resources/lib/libRlapack.dylib
-o libRlapack.dylib dlamc.lo dlapack0.lo dlapack1.lo
dlapack2.lo dlapack3.lo cmplx.lo cmplxblas.lo
/usr/lib/libgfortran.a ld: Undefined symbols: _dasum_
_daxpy_ _dcopy_ _ddot_ _dgemm_ _dgemv_ _dger_ _dnrm2_
_drot_ _dscal_ _dswap_ _dsymv_ _dsyrk_ _dtbsv_ _dtpsv_
_dtrmm_ _dtrmv_ _dtrsv_ _idamax_ _xerbla_ _dtpmv_ _dtrsm_
_dgbmv_ _dsbmv_ _dspmv_ _dspr2_ _dspr_ _dsymm_ _dsyr2_
_dsyr2k_ _dsyr_ _dtbmv_ _zgemm_ /usr/bin/libtool:
internal link edit command failed make[4]: ***
[libRlapack.dylib] Error 1 make[3]: *** [R] Error 2
make[2]: *** [R] Error 1 make[1]: *** [R] Error 1 make:
*** [R] Error 1

    Jan> ==========================================================
    Jan> Jan de Leeuw, 11667 Steinhoff Rd, Frazier Park, CA
    Jan> 93225, 661-245-1725
    Jan> http://www.cuddyvalley.org/dunklen.mov
    Jan> ==========================================================
    Jan> Und die Einen sind im Dunkeln Und die Andern sind im
    Jan> Licht Doch man sieht nur die im Lichte Die im Dunkeln
    Jan> sieht man nicht (Brecht)

I could be wrong, but I think there's something else wrong here.  
The farthest-up-the-chain problem that I can find is that the test  
for whether or not double complex BLAS can be used is failing. This  
is causing the use_lapack to get set back to no, which changes the  
args such that Makefile.in down in src/modules/lapack no longer  
tries to use the external lapack. Or at least that's the best I can  
make from this, but I'm not particularly skilled at reading (much  
less writing) autotools stuff.

I get a working version when I use f77, but when I use fink's  
gfortran/g95 I fail. Interestingly, using a fully rebuilt gfortran  
on my g5 works for me (or did as of a week or two ago) but I can't  
build gfortran from source on my g4 as it tries to build a "fat" (I  
mean "universal") binary with ppc64 support, which, of course  
doesn't exist on the g4.

Cyrus

On Aug 20, 2005, at 6:45 AM, Martin Maechler wrote:

"Jan" == Jan de Leeuw <deleeuw at stat.ucla.edu>
    on Fri, 19 Aug 2005 11:41:19 -0700 writes:

    Jan> The current R-devel version forgets to add "-framework
    Jan> vecLib" when linking libLapack.dylib. Go to
    Jan> src/modules/lapack, run make, then paste the failing
    Jan> link statement into terminal and add "-framework
    Jan> vecLib" to the end of it. Then go back to the top level
    Jan> and run make to finish the whole thing.

This may be fixable by changing
   <Rsource>/configure.ac   which produces  <Rsource>/configure
which later produces
   <Rbuild>/etc/Makeconf

Can you find out at least what changes are needed to etc/Makeconf
and forward your information to the R-devel mailing list ?

Thank you in advance,
Martin

    Jan> On Aug 19, 2005, at 11:35 , Kasper Daniel Hansen wrote:

Hi

I am trying to compile R-devel (the version from
yesterday) with a "vanilla" installation of Tiger on a
new Powerbook. Vanilla means I am running - Xcode 2.1 -
Gcc 4.0 - The gfortran build which Simon Urbanek has on
his wiki website (build number 5202) - make version "GNU
Make 3.80 " - libtool version "Apple Computer,
Inc. version cctools-590" - autoconf version "autoconf
(GNU Autoconf) 2.59 "

I do ./configure with the options ./configure
F77=gfortran FLIBS=/usr/lib/libgfortran.a --with-
blas='-framework vecLib' --with-lapack R_PAPERSIZE=letter
--with-aqua

(btw are these the "right" options?), which gives my the
configure output:

R is now configured for powerpc-apple-darwin8.2.0

Source directory: .  Installation directory:
/Library/Frameworks

C compiler: gcc -g -O2 C++ compiler: g++ -g -O2 Fortran
compiler: gfortran -g -O2

Interfaces supported: X11, aqua, tcltk External
libraries: readline Additional capabilities: iconv, MBCS,
NLS Options enabled: framework, R profiling

Recommended packages: yes

Making yields the error reproduced below.

How do I fix this? Shoudl I switch fortran compiler? Or
install another version of libtool? Or?

Kasper


Make error:

gcc -dynamiclib -L/usr/local/lib -install_name
/Library/Frameworks/
R.framework/Versions/2.2.0/Resources/lib/libRlapack.dylib
-o libRlapack.dylib dlamc.lo dlapack0.lo dlapack1.lo
dlapack2.lo dlapack3.lo cmplx.lo cmplxblas.lo
/usr/lib/libgfortran.a ld: Undefined symbols: _dasum_
_daxpy_ _dcopy_ _ddot_ _dgemm_ _dgemv_ _dger_ _dnrm2_
_drot_ _dscal_ _dswap_ _dsymv_ _dsyrk_ _dtbsv_ _dtpsv_
_dtrmm_ _dtrmv_ _dtrsv_ _idamax_ _xerbla_ _dtpmv_ _dtrsm_
_dgbmv_ _dsbmv_ _dspmv_ _dspr2_ _dspr_ _dsymm_ _dsyr2_
_dsyr2k_ _dsyr_ _dtbmv_ _zgemm_ /usr/bin/libtool:
internal link edit command failed make[4]: ***
[libRlapack.dylib] Error 1 make[3]: *** [R] Error 2
make[2]: *** [R] Error 1 make[1]: *** [R] Error 1 make:
*** [R] Error 1

    Jan> ==========================================================
    Jan> Jan de Leeuw, 11667 Steinhoff Rd, Frazier Park, CA
    Jan> 93225, 661-245-1725
    Jan> http://www.cuddyvalley.org/dunklen.mov
    Jan> ==========================================================
    Jan> Und die Einen sind im Dunkeln Und die Andern sind im
    Jan> Licht Doch man sieht nur die im Lichte Die im Dunkeln
    Jan> sieht man nicht (Brecht)

I could be wrong, but I think there's something else wrong here. The
farthest-up-the-chain problem that I can find is that the test for
whether or not double complex BLAS can be used is failing.

I get a working version when I use f77, but when I use fink's
gfortran/g95 I fail.

On Sun, 21 Aug 2005, Cyrus Harmon wrote:

I could be wrong, but I think there's something else wrong here. The
farthest-up-the-chain problem that I can find is that the test for
whether or not double complex BLAS can be used is failing.

<snip>>

I get a working version when I use f77, but when I use fink's
gfortran/g95 I fail.

That makes sense, as the test was put in because of differences in  
the ABI for double complex between g77 and gfortran on AMD64


    -thomas

I could be wrong, but I think there's something else wrong here. The
farthest-up-the-chain problem that I can find is that the test for
whether or not double complex BLAS can be used is failing. This is
causing the use_lapack to get set back to no, which changes the args
such that Makefile.in down in src/modules/lapack no longer tries to
use the external lapack. Or at least that's the best I can make from
this, but I'm not particularly skilled at reading (much less
writing) autotools stuff.

Ok, but, sense or not, the result of the failing test is that the the 
use_lapack is turned off and we don't link against the external lapack. Is 
this the desired behavior? If so there's probably a better solution than just 
breaking the build.

Ok, but, sense or not, the result of the failing test is that the  
the  use_lapack is turned off and we don't link against the  
external lapack. Is this the desired behavior? If so there's  
probably a better  solution than just breaking the build.

On Aug 24, 2005, at 4:43 PM, Simon Urbanek wrote:

On Aug 24, 2005, at 4:58 PM, Kasper Daniel Hansen wrote:

On Aug 24, 2005, at 11:09 AM, Simon Urbanek wrote:

I just repeat what I've said here already: unless you desperately
need 64-bit R there is no real benefit from using gcc4, because  
it's
still very instable (gfortran segfaults even on simple examples)  
and
unreliable (gfortran is even slower than g77). There is a good
reason
why the CRAN build uses gcc3 and g77.

That was a nice clear statement. So given that I want to compile R
from source (because I need the devel version), without too much
hassle I should use gcc 3.3 supplied by Xcode 2.1. But what do I do
with respect to the Fortran compiler?

CRAN installer package of R comes with g77 3.4 which is recommended.
You can install it even separately from the R binary (preferably
using sudo installer ... because there is a bug in the package that
doesn't allow non-admins to install it - c.f. the list). That version
is tested to work with the gcc3 that cones with Xcode 2.x. If you
plan to compile R from sources you may also want to run
sudo gcc_select 3.3
to prevent having problems with cc_dynamic.

How close should the versions match? Should I get
  - gcc 3.3.6 (latest version of the 3.3 branch) from Gnu's website
  - gcc 3.4.4 from Gnu's website
  - gcc 3.4 from the hpc.sourceforge website

It doesn't really matter as long as it is >=3.3 and <=3.9 except that
it should use static Fortran libraries if possible (unfortunately the
more recent ones don't).

It works!

So here is what I did:
1) Downloaded the most recent (binary) version of R from cran and
mounted the disk image.
2) installed the g77 compiler from the package by
   sudo installer  -pkg /Volumes/R-2.1.1/Packages/g77.pkg -target /
(if you just want to check the package information, do
   installer -pkg /Volumes/R-2.1.1/Packages/g77.pkg -pkginfo
)
3) compiled R using the flags
./configure --with-aqua \
   --with-blas='-framework vecLib' --with-lapack \
   --with-tcl-config=/Library/Frameworks/Tcl.framework/tclConfig.sh \
   --with-tk-config=/Library/Frameworks/Tk.framework/tkConfig.sh \
   R_PAPERSIZE=letter \
   F77=g77 \
   TCLTK_LIBS='-framework Tcl -framework Tk' \
   TCLTK_CPPFLAGS='-I/Library/Frameworks/Tcl.framework/Headers
                     -I/Library/Frameworks/Tk.frameworks/Headers'
(bad linebreak because of the mail program in the two last lines)

Thanks a lot!

Kasper



[[alternative HTML version deleted]]

Of course now you have R with AquaTcl, your Tcl/Tk based packages
will not work from the Aqua GUI, and packages such as tkrplot will not
work at all.

On Aug 25, 2005, at 11:17 , Kasper Daniel Hansen wrote:

On Aug 24, 2005, at 4:43 PM, Simon Urbanek wrote:

On Aug 24, 2005, at 4:58 PM, Kasper Daniel Hansen wrote:

On Aug 24, 2005, at 11:09 AM, Simon Urbanek wrote:

I just repeat what I've said here already: unless you desperately
need 64-bit R there is no real benefit from using gcc4, because
it's
still very instable (gfortran segfaults even on simple examples)
and
unreliable (gfortran is even slower than g77). There is a good
reason
why the CRAN build uses gcc3 and g77.

That was a nice clear statement. So given that I want to compile R
from source (because I need the devel version), without too much
hassle I should use gcc 3.3 supplied by Xcode 2.1. But what do I do
with respect to the Fortran compiler?

CRAN installer package of R comes with g77 3.4 which is recommended.
You can install it even separately from the R binary (preferably
using sudo installer ... because there is a bug in the package that
doesn't allow non-admins to install it - c.f. the list). That  
version
is tested to work with the gcc3 that cones with Xcode 2.x. If you
plan to compile R from sources you may also want to run
sudo gcc_select 3.3
to prevent having problems with cc_dynamic.

How close should the versions match? Should I get
  - gcc 3.3.6 (latest version of the 3.3 branch) from Gnu's website
  - gcc 3.4.4 from Gnu's website
  - gcc 3.4 from the hpc.sourceforge website

It doesn't really matter as long as it is >=3.3 and <=3.9 except  
that
it should use static Fortran libraries if possible (unfortunately  
the
more recent ones don't).

It works!

So here is what I did:
1) Downloaded the most recent (binary) version of R from cran and
mounted the disk image.
2) installed the g77 compiler from the package by
   sudo installer  -pkg /Volumes/R-2.1.1/Packages/g77.pkg -target /
(if you just want to check the package information, do
   installer -pkg /Volumes/R-2.1.1/Packages/g77.pkg -pkginfo
)
3) compiled R using the flags
./configure --with-aqua \
   --with-blas='-framework vecLib' --with-lapack \
   --with-tcl-config=/Library/Frameworks/Tcl.framework/tclConfig.sh \
   --with-tk-config=/Library/Frameworks/Tk.framework/tkConfig.sh \
   R_PAPERSIZE=letter \
   F77=g77 \
   TCLTK_LIBS='-framework Tcl -framework Tk' \
   TCLTK_CPPFLAGS='-I/Library/Frameworks/Tcl.framework/Headers
                     -I/Library/Frameworks/Tk.frameworks/Headers'
(bad linebreak because of the mail program in the two last lines)

Thanks a lot!

Kasper



[[alternative HTML version deleted]]

==========================================================
Jan de Leeuw, 11667 Steinhoff Rd, Frazier Park, CA 93225, 661-245-1725
                                  http://www.cuddyvalley.org/ 
dunklen.mov
==========================================================
                                      Und die Einen sind im Dunkeln
                                      Und die Andern sind im Licht
                                      Doch man sieht nur die im Lichte
                                      Die im Dunkeln sieht man
nicht       (Brecht)