Compiling Ifeffit wrapper, Athena, etc on AMD64 Linux Box
I've been running in to some problems getting Athena, Artemis, and the other add-on packages to ifeffit, compiled on my AMD Athlon-64 Linux box (running Fedora Core 3, 64-bit version). I can run "perl Makefile.PL" without any problems and get the message: Yay! Now type "make" then "make install" to finish ... Once I run "make" it gets to the point of putting everything together and I get the following message (after the rest of it appears to run successfully): gcc -shared ifeffit_wrap.o -o blib/arch/auto/Ifeffit/Ifeffit.so -L/usr/local/lib -lifeffit -L/usr/local/pgplot -lpgplot -lpng -lz -L/usr/X11R6/lib -lX11 -L/usr/lib/gcc/x86_64-redhat-linux/3.4.2 -L/usr/lib/gcc/x86_64-redhat-linux/3.4.2/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -lfrtbegin -lg2c -lm -lgcc_s /usr/bin/ld: /usr/local/lib/libifeffit.a(ifeffit.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/libifeffit.a: could not read symbols: Bad value collect2: ld returned 1 exit status make: *** [blib/arch/auto/Ifeffit/Ifeffit.so] Error Thus far I have: 1) Successfully installed PGPLOT-5.2.0, editing the makefile to read: LIBS=-L/usr/X11R6/lib64 -lX11 `$(SRC)/cpg/libgcc_path.sh` -lgcc -lm -lc instead of ... -L/usr/X11R6/lib -lX11 ... 2) Successfully installed ifeffit-1.2.6 after editing: src/Makefile src/cmdline/Makefile src/test/Makefile to contain: PGPLOT_LIBS = -L/usr/local/pgplot -lpgplot -lpng -lz -L/usr/X11R6/lib64 -lX11 instead of ... -L/usr/X11R6/lib -lX11 ... 3) Successfully installed Tk-804.027 after editing Makefile.PL to read: X11LIB=/usr/X11R6/lib64 4) began installing the ifeffit wrapper, athena and artemis with $ perl Makefile.PL (which completed successfully) $ make (gives errors) I've edited the Makefile in the horae-046 directory where ifeffit_wrap.c and ifeffit_wrap.o are located to append -fPIC following the call to gcc, producing: gcc -shared ifeffit_wrap.o -fPIC -o blib/arch/auto/Ifeffit/Ifeffit.so -L/usr/local/lib -lifeffit -L/usr/local/pgplot -lpgplot -lpng -lz -L/usr/X11R6/lib -lX11 -L/usr/lib/gcc/x86_64-redhat-linux/3.4.2 -L/usr/lib/gcc/x86_64-redhat-linux/3.4.2/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -lfrtbegin -lg2c -lm -lgcc_s /usr/bin/ld: /usr/local/lib/libifeffit.a(ifeffit.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/libifeffit.a: could not read symbols: Bad value collect2: ld returned 1 exit status make: *** [blib/arch/auto/Ifeffit/Ifeffit.so] Error 1 I'm no compiling wizard, and I'm not even certain that -fPIC is supposed to be passed to gcc in this manner. Is there some other way around the whole shared/static thing, or is this not even the real issue? If anyone on the list has any suggestions, by all means please send them along. I'd like to get some work done!! Sorry for the length of the post. Jake
Jake: I think that I have a reason (if not a solution) for this. The AMD64 is an architecture in which Position Independent Code matters. I believe that this is not the case for i386 (the 32 bit mode for the Opteron). The problem you are having is that ifeffit needs to be compiled with -fPIC so that you can link it to the wrapper. This means that you need to recompile ifeffit itself. Matt, Bruce? Is this correct? Can you suggest where Jake might make a change in the ifeffit configure script to make this work? I am not an expert on automake. I am interested in this myself as I have an opteron but have not been brave enough to try for a pure 64 bit install. Carlo On Wed, 8 Dec 2004 mjpushie@ucalgary.ca wrote:
I've been running in to some problems getting Athena, Artemis, and the other add-on packages to ifeffit, compiled on my AMD Athlon-64 Linux box (running Fedora Core 3, 64-bit version). I can run "perl Makefile.PL" without any problems and get the message: Yay! Now type "make" then "make install" to finish ...
Once I run "make" it gets to the point of putting everything together and I get the following message (after the rest of it appears to run successfully):
gcc -shared ifeffit_wrap.o -o blib/arch/auto/Ifeffit/Ifeffit.so -L/usr/local/lib -lifeffit -L/usr/local/pgplot -lpgplot -lpng -lz -L/usr/X11R6/lib -lX11 -L/usr/lib/gcc/x86_64-redhat-linux/3.4.2 -L/usr/lib/gcc/x86_64-redhat-linux/3.4.2/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -lfrtbegin -lg2c -lm -lgcc_s /usr/bin/ld: /usr/local/lib/libifeffit.a(ifeffit.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/libifeffit.a: could not read symbols: Bad value collect2: ld returned 1 exit status make: *** [blib/arch/auto/Ifeffit/Ifeffit.so] Error
Thus far I have: 1) Successfully installed PGPLOT-5.2.0, editing the makefile to read: LIBS=-L/usr/X11R6/lib64 -lX11 `$(SRC)/cpg/libgcc_path.sh` -lgcc -lm -lc instead of ... -L/usr/X11R6/lib -lX11 ...
2) Successfully installed ifeffit-1.2.6 after editing: src/Makefile src/cmdline/Makefile src/test/Makefile to contain: PGPLOT_LIBS = -L/usr/local/pgplot -lpgplot -lpng -lz -L/usr/X11R6/lib64 -lX11 instead of ... -L/usr/X11R6/lib -lX11 ...
3) Successfully installed Tk-804.027 after editing Makefile.PL to read: X11LIB=/usr/X11R6/lib64
4) began installing the ifeffit wrapper, athena and artemis with $ perl Makefile.PL (which completed successfully) $ make (gives errors)
I've edited the Makefile in the horae-046 directory where ifeffit_wrap.c and ifeffit_wrap.o are located to append -fPIC following the call to gcc, producing:
gcc -shared ifeffit_wrap.o -fPIC -o blib/arch/auto/Ifeffit/Ifeffit.so -L/usr/local/lib -lifeffit -L/usr/local/pgplot -lpgplot -lpng -lz -L/usr/X11R6/lib -lX11 -L/usr/lib/gcc/x86_64-redhat-linux/3.4.2 -L/usr/lib/gcc/x86_64-redhat-linux/3.4.2/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -lfrtbegin -lg2c -lm -lgcc_s /usr/bin/ld: /usr/local/lib/libifeffit.a(ifeffit.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/libifeffit.a: could not read symbols: Bad value collect2: ld returned 1 exit status make: *** [blib/arch/auto/Ifeffit/Ifeffit.so] Error 1
I'm no compiling wizard, and I'm not even certain that -fPIC is supposed to be passed to gcc in this manner. Is there some other way around the whole shared/static thing, or is this not even the real issue?
If anyone on the list has any suggestions, by all means please send them along. I'd like to get some work done!! Sorry for the length of the post.
Jake
_______________________________________________ Ifeffit mailing list Ifeffit@millenia.cars.aps.anl.gov http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit
-- Carlo U. Segre -- Professor of Physics Associate Dean for Special Projects, Graduate College Illinois Institute of Technology Voice: 312.567.3498 Fax: 312.567.3494 Carlo.Segre@iit.edu http://www.iit.edu/~segre
On Thursday 09 December 2004 12:39 am, Carlo U. Segre wrote:
I think that I have a reason (if not a solution) for this. The AMD64 is an architecture in which Position Independent Code matters. I believe that this is not the case for i386 (the 32 bit mode for the Opteron). The problem you are having is that ifeffit needs to be compiled with -fPIC so that you can link it to the wrapper. This means that you need to recompile ifeffit itself.
Matt, Bruce? Is this correct? Can you suggest where Jake might make a change in the ifeffit configure script to make this work? I am not an expert on automake.
I am interested in this myself as I have an opteron but have not been brave enough to try for a pure 64 bit install.
I have to confess ignorance here. I have not yet had the good fortune of having a 64 bit computer on my desk. At least as far as I am concerned, Jake is in uncharted territory. Hopefully Matt will have something more intelligent to say. (That's not so hard.... ;-) B -- Bruce Ravel ----------------------------------- ravel@phys.washington.edu Code 6134, Building 3, Room 405 Naval Research Laboratory phone: (1) 202 767 2268 Washington DC 20375, USA fax: (1) 202 767 4642 NRL Synchrotron Radiation Consortium (NRL-SRC) Beamlines X11a, X11b, X23b National Synchrotron Light Source Brookhaven National Laboratory, Upton, NY 11973 My homepage: http://feff.phys.washington.edu/~ravel EXAFS software: http://feff.phys.washington.edu/~ravel/software/exafs/
Jake, Carlo, Bruce, I think Carlo is essentially correct, and have no experience with 64bit linux either, so I'm not sure where the actual problem lies. As far as I understand, all the dynamic libraries would have to decide on basic stuff like how many bytes an 'int' uses, or at least know whether 'int' in some library meant 32bitInt or 64bitInt. So some questions for Jake would be: 1. does command-line 'ifeffit' work? Does it start up, does it read data, does it plot data? If not, perl is not the issue. I think perl's Makefile.PL will try to run ifeffit, so my guess is that ifeffit does work, at least some ;). 2. If ifeffit does run, do a 'ldd /usr/local/bin/ifeffit' (or whereever else ifeffit got installed to). This will report the dynamic libraries that ifeffit will try to load. Many of those will also be loaded by the perl library (Ifeffit.so), so that might give a hint of where to look for 32bit v 64bit libraries. If you ever get a perl Ifeffit.so to compile, you could run ldd on that too. 3. Did you compile a dynamic PGPLOT library? That is, is ifeffit linking with libpgplot.so or libpgplot.a? If the ldd command above lists libpgplot.so, then find and delete that file, and rebuild Ifeffit to use the static libpgplot.a. 4. Do you know that perl is not the problem? Do the perl/Tk demos work? Other than that, I'd google search, especially on the 'bad value collect2':
/usr/local/lib/libifeffit.a: could not read symbols: Bad value collect2: ld returned 1 exit status
I don't know where that's coming from. Could be related to the 64bit X11 libraries, but also might be fortran related....
I've edited the Makefile in the horae-046 directory where ifeffit_wrap.c and ifeffit_wrap.o are located to append -fPIC following the call to gcc, producing:
I'm not sure adding the -fPIC should be necessary. Whether this is needed seems to depend on gcc versions and other painfully weird things. Sorry for not being able to help more than that. On the bright side, there will be several happy people when you figure it out! --Matt
participants (4)
-
Bruce Ravel -
Carlo U. Segre -
Matt Newville -
mjpushie＠ucalgary.ca