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

2005-09-28 Thread Tom 'spot' Callaway
On Thu, 2005-09-22 at 10:36 +0100, Prof Brian Ripley wrote: > Probably because it is discussed in the R-admin manual as having > previously appeared in Debian and being traced to an erroneous patch to > the Lapack 3.0 sources. You wouldn't happen to have more specific details on this, would you

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

2005-09-28 Thread José Matos
Peter Dalgaard wrote: > -L/usr/lib64 I think. I have > > #LAPACK_LIBS="-L/usr/lib64 -llapack" > > (commented out now) in config.site. I'm sorry, it was my mistake. I forgot to install blas-devel where libblas.so is defined as a symbolic link to the correct library version. Since the confi

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

2005-09-28 Thread Peter Dalgaard
José Matos <[EMAIL PROTECTED]> writes: > Peter Dalgaard wrote: > > > Hmm. Doesn't look like it is actually working, though. Install > > lapack-devel, configure --with-lapack, and make check dies with > > > > running code in 'base-Ex.R' ...make[4]: *** [base-Ex.Rout] Error 1 > > make[4]: Leaving

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

2005-09-28 Thread José Matos
Peter Dalgaard wrote: > Hmm. Doesn't look like it is actually working, though. Install > lapack-devel, configure --with-lapack, and make check dies with > > running code in 'base-Ex.R' ...make[4]: *** [base-Ex.Rout] Error 1 > make[4]: Leaving directory `/home/pd/r-devel/BUILD/tests/Examples' > ma

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

2005-09-23 Thread José Matos
Prof Brian Ripley wrote: > I've seen that with mobile Pentium chips using ATLAS tuned on desktop > machines In the future (not now), since Intel plans to sell those chips to desktop machines, that will not be a bad thing. ;-) And yes, I do understand your point. :-) -- José Abílio ___

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

2005-09-23 Thread José Matos
Peter Dalgaard wrote: > Prof Brian Ripley wrote: >> BTW, I don't understand how a Linux distro can supply ATLAS tuned to >> my CPU/FPU. Dr Goto has had about ten versions of his optimized BLAS >> covering just a small subset of i686 CPUs. So although a distro's >> ATLAS may be better than a gener

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

2005-09-23 Thread José Matos
Peter Dalgaard wrote: > José Matos <[EMAIL PROTECTED]> writes: > >> The change was necessary to allow atlas to compile and interact with >> lapack. >> >> atlas is on the queue to Fedora Extras, it is in the review phase now. > > Hmm. Doesn't look like it is actually working, though. Install

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

2005-09-22 Thread Luke Tierney
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

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

2005-09-22 Thread Charles Geyer
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 is

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

2005-09-22 Thread Peter Dalgaard
Prof Brian Ripley <[EMAIL PROTECTED]> writes: > Which confirms the wisdom of our advice not to use --with-lapack > unless you have to (a few systems do). (Quote from the R-admin manual > > this is definitely *not* recommended > > . Perhaps this needs to say `use at your own risk and do no

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

2005-09-22 Thread Prof Brian Ripley
On Thu, 22 Sep 2005, Peter Dalgaard wrote: > running code in 'base-Ex.R' ...make[4]: *** [base-Ex.Rout] Error 1 > make[4]: Leaving directory `/home/pd/r-devel/BUILD/tests/Examples' > make[3]: *** [test-Examples-Base] Error 2 > > [EMAIL PROTECTED] BUILD]$ tail tests/Examples/base-Ex.Rout.fail

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

2005-09-22 Thread Prof Brian Ripley
Which confirms the wisdom of our advice not to use --with-lapack unless you have to (a few systems do). (Quote from the R-admin manual this is definitely *not* recommended . Perhaps this needs to say `use at your own risk and do not report problems with it'!) There are far too many

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

2005-09-22 Thread Peter Dalgaard
José Matos <[EMAIL PROTECTED]> writes: > Martyn Plummer wrote: > > > Fedora have just split off a separate lapack-devel package containing > > the static library and the symlink liblapack.so. (Mandrake/Mandriva has > > been doing this for some time. I don't know about SuSE). The up2date > > ser

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

2005-09-20 Thread 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 thes

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

2005-09-20 Thread Charles Geyer
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/i

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

2005-09-20 Thread José Matos
Martyn Plummer wrote: > Fedora have just split off a separate lapack-devel package containing > the static library and the symlink liblapack.so. (Mandrake/Mandriva has > been doing this for some time. I don't know about SuSE). The up2date > service will recognize that it needs to update lapack,

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

2005-09-19 Thread Gavin Simpson
On Mon, 2005-09-19 at 17:40 +0200, Martyn Plummer wrote: > On Mon, 2005-09-19 at 17:10 +0200, Peter Dalgaard wrote: > > Martyn Plummer <[EMAIL PROTECTED]> writes: > > > > > > The 'recompile with -fPIC' is bullsh*t. The problem is that is is > > > > looking > > > > in /usr/lib64/liblapack.a rathe

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

2005-09-19 Thread Martyn Plummer
On Mon, 2005-09-19 at 17:10 +0200, Peter Dalgaard wrote: > Martyn Plummer <[EMAIL PROTECTED]> writes: > > > > The 'recompile with -fPIC' is bullsh*t. The problem is that is is looking > > > in /usr/lib64/liblapack.a rather than /usr/lib64/liblapack.so.3 both of > > > which > > > exist. Some sea

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

2005-09-19 Thread Peter Dalgaard
Martyn Plummer <[EMAIL PROTECTED]> writes: > > The 'recompile with -fPIC' is bullsh*t. The problem is that is is looking > > in /usr/lib64/liblapack.a rather than /usr/lib64/liblapack.so.3 both of > > which > > exist. Some searching for this error message on Google shows a lot of > > questions

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

2005-09-19 Thread Martyn Plummer
On Sat, 2005-09-17 at 17:19 -0500, Charles Geyer wrote: > I can't compile R-alpha on AMD 64. Rather than include a 1400 line script > I have put it on the web > > http://www.stat.umn.edu/~charlie/typescript.txt > > way down near the bottom it fails building lapack.so > > gcc -shared -L/

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

2005-09-17 Thread Charles Geyer
I can't compile R-alpha on AMD 64. Rather than include a 1400 line script I have put it on the web http://www.stat.umn.edu/~charlie/typescript.txt way down near the bottom it fails building lapack.so gcc -shared -L/usr/local/lib64 -o lapack.so Lapack.lo-llapack -lblas -lg2c -lm -l