[Rd] looks in liblapack.a not liblapack.so
Charles Geyer
charlie at stat.umn.edu
Thu Sep 22 20:23:57 CEST 2005
On Tue, Sep 20, 2005 at 09:43:51PM -0500, Luke Tierney wrote:
> On Tue, 20 Sep 2005, Charles Geyer wrote:
> >
> >I still don't understand why gcc -shared even bothers to look in *.a
> >(on AMD64) when it won't do the slightest bit of good. Maybe I'm still
> >ignorant of some important technical issue (maybe? more like with very
> >high probability!)
> >
>
> The issue is not the library but whether the code is compiled as
> position-independent code (PIC) or not. Many .a libraries are built
> as PIC and they can be used to create shared objects, you just get
> copies of the modules you use linked in. PIC code can be slower,
> which is why some prefer to build .a libraries as non-PIC.
Oh. Thanks. That makes it all clear. If I compile cddlib with
export CXX=gcc
export CFLAGS="-O -fPIC"
./configure --prefix=/APPS/64/
then I can build rcdd and it works! (And, you're right, the fact that
cddlib builds libcddgmp.a instead of libcddgmp.so is irrelevant, it's
the -fPIC that matters.)
> I'm not sure why one rarely runs into non-PIC issues on i386--it may
> be that gcc at least is always producing PIC code there. It does come
> up on other architectures though, in particular on x86_64. It seems
> that most Linux distros that provide pvm only provide .a libraries,
> but some build these with PIC some don't. Red Hat Enterprise WS4
> seems to be non-PIC, FC3 and FC4 seem to be PIC. If your distro is
> non-PIC you will need to build your own PIC version of pvm and tell
> rpvm where to find it.
snowbank$ locate pvm | grep -E '\.so|\.a$'
/usr/lib/pvm3/lib/LINUX64/libfpvm3.a
/usr/lib/pvm3/lib/LINUX64/libgpvm3.a
/usr/lib/pvm3/lib/LINUX64/libpvm3.a
/usr/lib/pvm3/lib/LINUX64/libpvmtrc.a
/usr/lib64/libpvm3.so
/usr/lib64/libpvm3.so.3
/usr/lib64/libpvm3.so.3.4
I think I've got the libraries, so
> install.packages("rpvm", repos = "http://www.biometrics.mtu.edu/CRAN/")
trying URL 'http://www.biometrics.mtu.edu/CRAN/src/contrib/rpvm_0.6-5.tar.gz'
[lots of blather deleted]
gcc -shared -L/usr/local/lib64 -o rpvm.so rpvm_core.o rpvm_ser.o utils.o -L/usr/lib/pvm3/lib/LINUX64 -lpvm3 -lgpvm3 -lreadline -lncurses
/usr/lib64/gcc-lib/x86_64-suse-linux/3.3.5/../../../../x86_64-suse-linux/bin/ld: /usr/lib/pvm3/lib/LINUX64/libpvm3.a(lpvmgen.o): relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC
same problem, I have a .so (presumably PIC), but it's picked another library.
Reading the help for install.packages, I don't find anything about how to
make it link against /usr/lib64/libpvm3.so instead
of /usr/lib/pvm3/lib/LINUX64/libpvm3.a so I guess that means do it by hand.
I'm a little puzzled by that too. Apparently the configure in rpvm wants
to use PVM_ROOT which for this (SuSE 9.3 AMD64) box is /usr/lib/pvm3 (which
is the default) to find the libraries it wants to link to, but that won't
work. The appropriate library is /usr/lib64/libpvm3.so -- maybe.
I just noticed the -lpvm3 -lgpvm3 in the link that failed. I'm not
sure /usr/lib64/libpvm3.so contains everything rpvm needs.
This just isn't going to work with the SuSE provided pvm stuff right?
I untarred the rpvm package and did R CMD check on it and it really
doesn't give any way to link to a library in an odd place -- at least
not that I can see.
--
Charles Geyer
Professor, School of Statistics
University of Minnesota
charlie at stat.umn.edu
More information about the R-devel
mailing list