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

[Luke Tierney]

On Tue, 20 Sep 2005, Charles Geyer wrote:

> On Mon, Sep 19, 2005 at 10:44:00AM +0200, Martyn Plummer wrote:
>> On Sat, 2005-09-17 at 17:19 -0500, Charles Geyer wrote:
>>> I can't compile R-alpha on AMD 64 ...
>>
>> You would need to modify the LDFLAGS and CPPFLAGS environment variables,
>> as these default to -L/usr/local/lib and -I/usr/local/include
>> respectively.  See Appendix B.3.3 of the R Installation and
>> Administration manual, which gives a warning about 64-bit systems.
>
> That does not help.  The problem has (apparently) nothing to do
> with /usr/local (and the 32 bit compatibility libraries we have there).
>
>> You can also use the --with-readline configure flag to specify the exact
>> location of the readline library you wish to use.
>
> That's it.  I need
>
> ./configure --prefix=/APPS/Foo/Alpha64 --with-lapack=/usr/lib64/liblapack.so.3
>
>> I hope this helps.
>
> Yes it does.  Everything seems to work except the rpvm and rcdd contributed
> packages did not install.  Looking at the problem with rcdd, I see what the
> main problem was all along.  On 32 bit you can extract a .o out of a .a to
> put in a .so.  On 64 bit, you can't.  It's pickier apparently.  The makefile
> for cddlib doesn't make shared libraries, so I'm out of luck for rcdd on AMD64
> until I get that fixed.
>
> Now this problem makes a lot more sense.
>
> Sorry to be so stupid.  I knew you could do --with-lapack=something but forgot
> (meaning I have a vague recollection of reading about this once, now that I'm
> reminded of it).
>
> Anyway we now have R-2.2.0 alpha on AMD64 on SuSE 9.3 with
>
>> dim(installed.packages())
> [1] 80 10
>
> Thanks for the help.
>
> 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.

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.

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