From charlie at stat.umn.edu  Thu Sep 22 20:23:57 2005
From: charlie at stat.umn.edu (Charles Geyer)
Date: Thu, 22 Sep 2005 13:23:57 -0500
Subject: [Rd] looks in liblapack.a not liblapack.so
In-Reply-To: <Pine.LNX.4.63.0509202124040.9741@itasca2.wildberry.org>
References: <mailman.9.1126951201.11292.r-devel@r-project.org>
	<20050917221902.GA10806@stat.umn.edu>
	<1127119440.3624.5.camel@seurat>
	<20050921011941.GA22326@stat.umn.edu>
	<Pine.LNX.4.63.0509202124040.9741@itasca2.wildberry.org>
Message-ID: <20050922182357.GA10196@stat.umn.edu>

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



[Rd] looks in liblapack.a not liblapack.so
Charles Geyer