From luke at stat.uiowa.edu  Thu Sep 22 22:24:41 2005
From: luke at stat.uiowa.edu (Luke Tierney)
Date: Thu, 22 Sep 2005 15:24:41 -0500 (CDT)
Subject: [Rd] looks in liblapack.a not liblapack.so
In-Reply-To: <20050922182357.GA10196@stat.umn.edu>
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>
	<20050922182357.GA10196@stat.umn.edu>
Message-ID: <Pine.LNX.4.63.0509221516070.3838@nokomis.stat.uiowa.edu>

On Thu, 22 Sep 2005, Charles Geyer wrote:

> 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.

I would run configure in the untarred package then edit src/Makevars
to remove the -L bit and the -lgpvm and see if that works.  If not,
I'd get the pvm source, build libpvm.a and liggpvm.a with -fPIC files,
and fix src/Makevars to use them.  I'm sure there are more elegant
alternatives, but ...

luke

-- 
Luke Tierney
Chair, Statistics and Actuarial Science
Ralph E. Wareham Professor of Mathematical Sciences
University of Iowa                  Phone:             319-335-3386
Department of Statistics and        Fax:               319-335-3017
    Actuarial Science
241 Schaeffer Hall                  email:      luke at stat.uiowa.edu
Iowa City, IA 52242                 WWW:  http://www.stat.uiowa.edu



[Rd] looks in liblapack.a not liblapack.so
Luke Tierney