linked libraries?
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}}