[R-SIG-Mac] linked libraries?

[Simon Urbanek]

Paul,

as long as the routines are the same, it is quite harmless. However,  
in your case the other competing routines are from vecLib, so you  
never know. You may try to use vecLib directly (-framework vecLib) or  
even better use LAPACK_LIBS and BLAS_LIBS flags from R, e.g.:

R CMD SHLIB a.f '${LAPACK_LIBS} ${BLAS_LIBS}'

I can't reproduce your problem with the current R and gfortran, so  
I'm hoping you're using your own corresponding R binary for your  
compiler. I don't have gcc 3 machine anymore, so good luck..

Cheers,
Simon


On Sep 11, 2007, at 12:36 AM, Paul Rathouz wrote:

> I am writing some Fortran programs to be linked into R using
> dyn.load() and .Fortran().  I am using R CMD SHLIB to compile and
> link.  In my code, a few of the subroutines that I am using are from
> LINPACK/BLAS.  I am not sure if they are the same versions as those
> used by R.  As an example, I might issue:
>
> local% R CMD SHLIB testwrite.f dmattool.f linpack.f
> g77   -fno-common  -g -O2 -c testwrite.f -o testwrite.o
> g77   -fno-common  -g -O2 -c dmattool.f -o dmattool.o
> g77   -fno-common  -g -O2 -c linpack.f -o linpack.o
> gcc-3.3 -bundle -flat_namespace -undefined suppress -L/usr/local/lib
> -o testwrite.so testwrite.o dmattool.o linpack.o
> -L/usr/local/lib/gcc/powerpc-apple-darwin6.8/3.4.2 -lg2c -lSystem
> -lcc_dynamic -F/Library/Frameworks/R.framework/.. -framework R
> local%
>
> where linpack.f contains the BLAS subroutines I am using.  That is all
> fine.  However, if I modify testwrite.f to call Fortran subroutines
> RWARN or DBLEPR which are part of the R package and used for sending
> warnings and printing back to R, then I get:
>
> local% R CMD SHLIB testwrite.f dmattool.f linpack.f
> g77   -fno-common  -g -O2 -c testwrite.f -o testwrite.o
> g77   -fno-common  -g -O2 -c dmattool.f -o dmattool.o
> g77   -fno-common  -g -O2 -c linpack.f -o linpack.o
> gcc-3.3 -bundle -flat_namespace -undefined suppress -L/usr/local/lib
> -o testwrite.so testwrite.o dmattool.o linpack.o
> -L/usr/local/lib/gcc/powerpc-apple-darwin6.8/3.4.2 -lg2c -lSystem
> -lcc_dynamic -F/Library/Frameworks/R.framework/.. -framework R
> ld: warning multiple definitions of symbol _dasum_
> linpack.o definition of _dasum_ in section (__TEXT,__text)
> /System/Library/Frameworks/Accelerate.framework/Versions/A/ 
> Frameworks/vecLib.framework/Versions/A/libBLAS.dylib(single
> module) definition of _dasum_
> ld: warning multiple definitions of symbol _daxpy_
> linpack.o definition of _daxpy_ in section (__TEXT,__text)
> /System/Library/Frameworks/Accelerate.framework/Versions/A/ 
> Frameworks/vecLib.framework/Versions/A/libBLAS.dylib(single
> module) definition of _daxpy_
> [rest deleted]
>
> That is, the compiler/linker (g77, gcc) must be linking in some BLAS
> routines as a result of calling RWARN or DBLEPR.  The program still
> seems to run fine, but what is the best way to handle this situation?
> Can I just drop my file linpack.f and link in the BLAS routines
> directly?  If so, how do I do that and know exactly what versions of
> the routines are being linked in by SHLIB?  Alternatively, is there
> someway to avoid the duplication of symbol names?  Or, is the whole
> thing just harmless?
>
> -- pr
>
>
> ====================================================================== 
> ===
> Paul Rathouz, Assoc. Professor of Biostatistics           ph  
> 773-834-1970
> Dept. of Health Studies, Rm. W-264                       fax  
> 773-702-1979
> University of Chicago                                
> prathouz at uchicago.edu
> 5841 S. Maryland Ave. MC 2007
> Chicago, IL  60637
> ====================================================================== 
> ===
>
>
> This email is intended only for the use of the individual ...{{dropped}}