From charlie at stat.umn.edu  Wed Sep 21 03:19:41 2005
From: charlie at stat.umn.edu (Charles Geyer)
Date: Tue, 20 Sep 2005 20:19:41 -0500
Subject: [Rd] looks in liblapack.a not liblapack.so
In-Reply-To: <1127119440.3624.5.camel@seurat>
References: <mailman.9.1126951201.11292.r-devel@r-project.org>
	<20050917221902.GA10806@stat.umn.edu>
	<1127119440.3624.5.camel@seurat>
Message-ID: <20050921011941.GA22326@stat.umn.edu>

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!)

-- 
Charles Geyer
Professor, School of Statistics
University of Minnesota
charlie at stat.umn.edu



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