Hello, I've been put in charge of setting up a Dell 64bit Xeon workstation and on the side I've been tring to get scipy to install, but I haven't had any luck. I compiled LAPACK, BLAS, and ATLAS sucsesfuly and scipy finds them. Its when I try to build scipy that I get problems. I try just plain "./setup.py build" and I get these errors: /usr/bin/ld: /usr/lib/gcc-lib/x86_64-redhat-linux/3.2.3/libg2c.a(s_stop.o): relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC /usr/lib/gcc-lib/x86_64-redhat-linux/3.2.3/libg2c.a: could not read symbols: Bad value collect2: ld returned 1 exit status /usr/bin/ld: /usr/lib/gcc-lib/x86_64-redhat-linux/3.2.3/libg2c.a(s_stop.o): relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC /usr/lib/gcc-lib/x86_64-redhat-linux/3.2.3/libg2c.a: could not read symbols: Bad value collect2: ld returned 1 exit status error: Command "/usr/bin/g77 -shared build/temp.linux-x86_64-2.4/Lib/special/cephesmodule.o build/temp.linux-x86_64-2.4/Lib/special/amos_wrappers.o build/temp.linux-x86_64-2.4/Lib/special/specfun_wrappers.o build/temp.linux-x86_64-2.4/Lib/special/toms_wrappers.o build/temp.linux-x86_64-2.4/Lib/special/cdf_wrappers.o build/temp.linux-x86_64-2.4/Lib/special/ufunc_extras.o -Lbuild/temp.linux-x86_64-2.4 -lamos -ltoms -lc_misc -lcephes -lmach -lcdf -lspecfun -lg2c -o build/lib.linux-x86_64-2.4/scipy/special/cephes.so" failed with exit status 1 I also installed Intel's compiler, but I get different errors: ld: skipping incompatible build/temp.linux-x86_64-2.4/libc_misc.a when searching for -lc_misc ld: cannot find -lc_misc ld: skipping incompatible build/temp.linux-x86_64-2.4/libc_misc.a when searching for -lc_misc ld: cannot find -lc_misc error: Command "/usr/local/intel/bin/ifort -shared -nofor_main build/temp.linux-x86_64-2.4/Lib/special/cephesmodule.o build/temp.linux-x86_64-2.4/Lib/special/amos_wrappers.o build/temp.linux-x86_64-2.4/Lib/special/specfun_wrappers.o build/temp.linux-x86_64-2.4/Lib/special/toms_wrappers.o build/temp.linux-x86_64-2.4/Lib/special/cdf_wrappers.o build/temp.linux-x86_64-2.4/Lib/special/ufunc_extras.o -Lbuild/temp.linux-x86_64-2.4 -lamos -ltoms -lc_misc -lcephes -lmach -lcdf -lspecfun -o build/lib.linux-x86_64-2.4/scipy/special/cephes.so" failed with exit status 1 In trying to figure out whats wrong, I changed some items in scipy_distutils. I'm running Fedora Core 4 x86_64, so I had scipy looking in /usr/lib64 and /usr/X11R6/lib64 for libraries. I also set scipy to use gcc32, just because when I compiled ATLAS Don't fear that philosophy's an impious way --superstition's more likely to lead folk astray. ~Lucretius, De rerum natura, Book One http://mindbender.deviantart.com __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
On Tue, 12 Jul 2005 08:07:10 -0700 (PDT), David Noriega <neruocomp@yahoo.com> wrote :
Hello, I've been put in charge of setting up a Dell 64bit Xeon workstation and on the side I've been tring to get scipy to install, but I haven't had any luck. I compiled LAPACK, BLAS, and ATLAS sucsesfuly and scipy finds them. Its when I try to build scipy that I get problems. I try just plain "./setup.py build" and I get these errors:
Hello,
/usr/bin/ld: /usr/lib/gcc-lib/x86_64-redhat-linux/3.2.3/libg2c.a(s_stop.o): relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC
It seems that your gcc installation is somewhat messed up (libg2c hasn't been compiled with -fPIC) IMHO, best you can do to see if it's the problem is to compile your own gcc (try 3.4.3 instead of 4.0.0 which seems a little buggy). Don't be afraid : it's not that hard. Regards,
Well thats easier said then done on a fedora/redhat system. I know enought to get rpmbuild to rebuild gcc for me, but how would I get it to recompile gcc with -fPIC. Any ideas as to which file I should edit and where to put "-fPIC"? --- Nicolas Pernetty <nicopernetty@yahoo.fr> wrote:
On Tue, 12 Jul 2005 08:07:10 -0700 (PDT), David Noriega <neruocomp@yahoo.com> wrote :
Hello, I've been put in charge of setting up a Dell 64bit Xeon workstation and on the side I've been tring to get scipy to install, but I haven't had any luck. I compiled LAPACK, BLAS, and ATLAS sucsesfuly and scipy finds them. Its when I try to build scipy that I get problems. I try just plain "./setup.py build" and I get these errors:
Hello,
/usr/bin/ld:
/usr/lib/gcc-lib/x86_64-redhat-linux/3.2.3/libg2c.a(s_stop.o):
relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC
It seems that your gcc installation is somewhat messed up (libg2c hasn't been compiled with -fPIC) IMHO, best you can do to see if it's the problem is to compile your own gcc (try 3.4.3 instead of 4.0.0 which seems a little buggy). Don't be afraid : it's not that hard.
Regards,
_______________________________________________ SciPy-user mailing list SciPy-user@scipy.net http://www.scipy.net/mailman/listinfo/scipy-user
Don't fear that philosophy's an impious way --superstition's more likely to lead folk astray. ~Lucretius, De rerum natura, Book One http://mindbender.deviantart.com __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Well I did some more looking around and found that my problem was that I didnt have the 64bit package for libg2c. Its a bit weird with this system since it installs both i386 and x86_64 for some packages. Well that fixed this problem, I have a new one. It seems I need to build the ATLAS libraries with -fPIC /usr/bin/g77 -shared build/temp.linux-x86_64-2.4/build/src/Lib/optimize/lbfgsb-0.9/_lbfgsbmodule.o build/temp.linux-x86_64-2.4/build/src/fortranobject.o build/temp.linux-x86_64-2.4/Lib/optimize/lbfgsb-0.9/routines.o -L/usr/local/lib/atlas -Lbuild/temp.linux-x86_64-2.4 -llapack -lf77blas -lcblas -latlas -lg2c -o build/lib.linux-x86_64-2.4/scipy/optimize/_lbfgsb.so /usr/bin/ld: /usr/local/lib/atlas/liblapack.a(dpotrf.o): relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC /usr/local/lib/atlas/liblapack.a: could not read symbols: Bad value collect2: ld returned 1 exit status /usr/bin/ld: /usr/local/lib/atlas/liblapack.a(dpotrf.o): relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC /usr/local/lib/atlas/liblapack.a: could not read symbols: Bad value collect2: ld returned 1 exit status error: Command "/usr/bin/g77 -shared build/temp.linux-x86_64-2.4/build/src/Lib/optimize/lbfgsb-0.9/_lbfgsbmodule.o build/temp.linux-x86_64-2.4/build/src/fortranobject.o build/temp.linux-x86_64-2.4/Lib/optimize/lbfgsb-0.9/routines.o -L/usr/local/lib/atlas -Lbuild/temp.linux-x86_64-2.4 -llapack -lf77blas -lcblas -latlas -lg2c -o build/lib.linux-x86_64-2.4/scipy/optimize/_lbfgsb.so" failed with exit status 1 I'll keep you posted on my progress. I also wanted to point out something in scipy_distutils. The way cpuinfo.py is currently setup, it will not find that this system uses a Xeon processor. also it will fail to recongize it as having sse3. Looking at /proc/cpuinfo, Xeon is not in all caps and sse3, while it should be there, only comes up as ss. But that might just be a kernel thing as I fixed it in cpuinfo.py. --- David Noriega <neruocomp@yahoo.com> wrote:
Well thats easier said then done on a fedora/redhat system. I know enought to get rpmbuild to rebuild gcc for me, but how would I get it to recompile gcc with -fPIC. Any ideas as to which file I should edit and where to put "-fPIC"?
--- Nicolas Pernetty <nicopernetty@yahoo.fr> wrote:
On Tue, 12 Jul 2005 08:07:10 -0700 (PDT), David Noriega <neruocomp@yahoo.com> wrote :
Hello, I've been put in charge of setting up a Dell 64bit Xeon workstation and on the side I've been tring to get scipy to install, but I haven't had any luck. I compiled LAPACK, BLAS, and ATLAS sucsesfuly and scipy finds them. Its when I try to build scipy that I get problems. I try just plain "./setup.py build" and I get these errors:
Hello,
/usr/bin/ld:
/usr/lib/gcc-lib/x86_64-redhat-linux/3.2.3/libg2c.a(s_stop.o):
relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC
It seems that your gcc installation is somewhat messed up (libg2c hasn't been compiled with -fPIC) IMHO, best you can do to see if it's the problem is to compile your own gcc (try 3.4.3 instead of 4.0.0 which seems a little buggy). Don't be afraid : it's not that hard.
Regards,
_______________________________________________ SciPy-user mailing list SciPy-user@scipy.net http://www.scipy.net/mailman/listinfo/scipy-user
Don't fear that philosophy's an impious way --superstition's more likely to lead folk astray.
~Lucretius, De rerum natura, Book One
http://mindbender.deviantart.com
__________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
_______________________________________________ SciPy-user mailing list SciPy-user@scipy.net http://www.scipy.net/mailman/listinfo/scipy-user
Don't fear that philosophy's an impious way --superstition's more likely to lead folk astray. ~Lucretius, De rerum natura, Book One http://mindbender.deviantart.com __________________________________ Yahoo! Mail Stay connected, organized, and protected. Take the tour: http://tour.mail.yahoo.com/mailtour.html
On Tue, 12 Jul 2005 14:51:08 -0700 (PDT), David Noriega <neruocomp@yahoo.com> wrote :
Well I did some more looking around and found that my problem was that I didnt have the 64bit package for libg2c. Its a bit weird with this system since it installs both i386 and x86_64 for some packages. Well that fixed this problem,
Good !
I have a new one. It seems I need to build the ATLAS libraries with -fPIC
/usr/bin/g77 -shared build/temp.linux-x86_64-2.4/build/src/Lib/optimize/lbfgsb-0.9/_lbfgsb module.o build/temp.linux-x86_64-2.4/build/src/fortranobject.o build/temp.linux-x86_64-2.4/Lib/optimize/lbfgsb-0.9/routines.o -L/usr/local/lib/atlas -Lbuild/temp.linux-x86_64-2.4 -llapack -lf77blas -lcblas -latlas -lg2c -o build/lib.linux-x86_64-2.4/scipy/optimize/_lbfgsb.so /usr/bin/ld: /usr/local/lib/atlas/liblapack.a(dpotrf.o): relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC /usr/local/lib/atlas/liblapack.a: could not read symbols: Bad value
-fPIC again...
I'll keep you posted on my progress. I also wanted to point out something in scipy_distutils. The way cpuinfo.py is currently setup, it will not find that this system uses a Xeon processor. also it will fail to recongize it as having sse3. Looking at /proc/cpuinfo, Xeon is not in all caps and sse3, while it should be there, only comes up as ss. But that might just be a kernel thing as I fixed it in cpuinfo.py.
I've just managed to compile SciPy on a RedHat Advanced Server 3 on an IA-64, so I guess you're near to succeed too ! I've also tried to use the default atlas and lapack given by RedHat but it somehow didn't fit (couldn't remember the errors though). After having much trouble compiling both for Solaris and HP-UX, doing it on a Linux box was much more simpler (didn't say easy), so I recompile atlas and lapack and managed to compile SciPy. Numeric is really simple to compile, could you try to compile it with your atlas/lapack to see if you still got the error ? (you have to manually edit setup.py to indicate paths to atlas/lapack) That would prove that the problem is inside atlas/lapack. If that's the case I could help you compiling them. Keep us informed ! Regards,
--- David Noriega <neruocomp@yahoo.com> wrote:
Well thats easier said then done on a fedora/redhat system. I know enought to get rpmbuild to rebuild gcc for me, but how would I get it to recompile gcc with -fPIC. Any ideas as to which file I should edit and where to put "-fPIC"?
--- Nicolas Pernetty <nicopernetty@yahoo.fr> wrote:
On Tue, 12 Jul 2005 08:07:10 -0700 (PDT), David Noriega <neruocomp@yahoo.com> wrote :
Hello, I've been put in charge of setting up a Dell 64bit Xeon workstation and on the side I've been tring to get scipy to install, but I haven't had any luck. I compiled LAPACK, BLAS, and ATLAS sucsesfuly and scipy finds them. Its when I try to build scipy that I get problems. I try just plain "./setup.py build" and I get these errors:
Hello,
/usr/bin/ld:
/usr/lib/gcc-lib/x86_64-redhat-linux/3.2.3/libg2c.a(s_stop.o):
relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC
It seems that your gcc installation is somewhat messed up (libg2c hasn't been compiled with -fPIC) IMHO, best you can do to see if it's the problem is to compile your own gcc (try 3.4.3 instead of 4.0.0 which seems a little buggy). Don't be afraid : it's not that hard.
Regards,
_______________________________________________ SciPy-user mailing list SciPy-user@scipy.net http://www.scipy.net/mailman/listinfo/scipy-user
Don't fear that philosophy's an impious way --superstition's more likely to lead folk astray.
~Lucretius, De rerum natura, Book One
http://mindbender.deviantart.com
__________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
_______________________________________________ SciPy-user mailing list SciPy-user@scipy.net http://www.scipy.net/mailman/listinfo/scipy-user
Don't fear that philosophy's an impious way --superstition's more likely to lead folk astray.
~Lucretius, De rerum natura, Book One
http://mindbender.deviantart.com
__________________________________ Yahoo! Mail Stay connected, organized, and protected. Take the tour: http://tour.mail.yahoo.com/mailtour.html
_______________________________________________ SciPy-user mailing list SciPy-user@scipy.net http://www.scipy.net/mailman/listinfo/scipy-user
On Wed, 13 Jul 2005 00:46:09 +0200 Nicolas Pernetty <nicopernetty@yahoo.fr> wrote:
I have a new one. It seems I need to build the ATLAS libraries with -fPIC
/usr/bin/g77 -shared build/temp.linux-x86_64-2.4/build/src/Lib/optimize/lbfgsb-0.9/_lbfg sb module.o build/temp.linux-x86_64-2.4/build/src/fortranobject.o build/temp.linux-x86_64-2.4/Lib/optimize/lbfgsb-0.9/routines.o -L/usr/local/lib/atlas -Lbuild/temp.linux-x86_64-2.4 -llapack -lf77blas -lcblas -latlas -lg2c -o build/lib.linux-x86_64-2.4/scipy/optimize/_lbfgsb.so /usr/bin/ld: /usr/local/lib/atlas/liblapack.a(dpotrf.o): relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC /usr/local/lib/atlas/liblapack.a: could not read symbols: Bad value
-fPIC again...
Setting the environment flag CFLAGS=-fPIC might work. If ATLAS uses configure to setup Makefiles you will need to set this before running it again. (e.g. CFLAGS=-fPIC ./configure --prefix=/usr/local/). I have not done this with ATLAS, but this is how I solved the same problem compiling other software. cheers! Ed
I would like to report the partial working of Scipy on a 64bit Xeon. I figured out that it was LAPACK that was causing problems. Luckly there is an rpm for my distro and arch. I used that to compleate ATLAS, after recompiling it with -fPIC. I then ran the scipy test and got one fail, four errors. Something about arrays. I installed Numeric with an rpm. So I uninstalled that one and installed the latest version from the source. That got rid of the errors, but the test still had one failure. FAIL: check_round (scipy.special.basic.test_basic.test_round) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib64/python2.4/site-packages/scipy/special/tests/test_basic.py", line 1789, in check_round assert_array_equal(rnd,rndrl) File "/usr/lib64/python2.4/site-packages/scipy_test/testing.py", line 715, in assert_array_equal assert cond,\ AssertionError: Arrays are not equal (mismatch 25.0%): Array 1: [10 10 11 11] Array 2: [10 10 10 11] ---------------------------------------------------------------------- Ran 690 tests in 1.340s This is using the latest ATLAS with the cvs source of Scipy. The normal scipy wouldn't even compile. I get declaration errors when it compiles ranlib_all.c error: Command "gcc -pthread -fno-strict-aliasing -DNDEBUG -O2 -g -pipe -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -m64 -mtune=nocona -D_GNU_SOURCE -fPIC -fPIC -I/usr/include/python2.4 -c Lib/stats/ranlib_all.c -o build/temp.linux-x86_64-2.4/Lib/stats/ranlib_all.o" failed with exit status 1 I guess this should get to the developers, but I'm not part of that mailing list. If someone could pass it on, that would be great. Don't fear that philosophy's an impious way --superstition's more likely to lead folk astray. ~Lucretius, De rerum natura, Book One http://mindbender.deviantart.com ____________________________________________________ Start your day with Yahoo! - make it your home page http://www.yahoo.com/r/hs
participants (3)
-
David Noriega -
Ed Rahn -
Nicolas Pernetty