looks in liblapack.a not liblapack.so
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