psLib fails to compile - could nto read symbold from libfftw3f.a: Bad value

[jester@…]

psLib fails to compile with the following error (what's the bugzilla component for psLib?):

/usr/lib64/gcc/x86_64-suse-linux/4.1.2/../../../../x86_64-suse-linux/bin/ld: /IPP/ipp-2.3.lin64lib/libfftw3f.a(plan-dft-r2c-1d.o): relocation R_X
86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC
/IPP/ipp-2.3.lin64lib/libfftw3f.a: could not read symbols: Bad value

Here's the context:

make[3]: Entering directory `/disk1/jester/IPP/ipp-2.3/psLib/src'
/bin/sh ../libtool --tag=CC --mode=link gcc -std=gnu99 -pipe -O0 -g -Wall -Werror -D_XOPEN_SOURCE=600 -D_POSIX_C_SOURCE=200112L -version-info 1:
1:0 -o libpslib.la -rpath /IPPipp-2.3.lin64/lib sys/libpslibsys.la astro/libpslibastro.la db/libpslibdb.la fft/libpslibfft.la fits/libpslibfits
.la imageops/libpslibimageops.la jpeg/libpslibjpeg.la math/libpslibmath.la mathtypes/libpslibmathtypes.la types/libpslibtypes.la -pthread -L/usr/l
ib64/mysql -lmysqlclient -lz -lcrypt -lnsl -lm -lcfitsio -lm -lfftw3f -L/IPPipp-2.3.lin64/lib -lgsl -lgslcblas -lm -ljpeg
mkdir .libs
gcc -std=gnu99 -shared -Wl,--whole-archive sys/.libs/libpslibsys.a astro/.libs/libpslibastro.a db/.libs/libpslibdb.a fft/.libs/libpslibfft.a fits/
.libs/libpslibfits.a imageops/.libs/libpslibimageops.a jpeg/.libs/libpslibjpeg.a math/.libs/libpslibmath.a mathtypes/.libs/libpslibmathtypes.a type
s/.libs/libpslibtypes.a -Wl,--no-whole-archive -Wl,--rpath -Wl,/usr/lib64/mysql -Wl,--rpath -Wl,/IPPipp-2.3.lin64/lib -Wl,--rpath -Wl,/usr/lib64
/mysql -Wl,--rpath -Wl,/IPPipp-2.3.lin64/lib -L/usr/lib64/mysql /usr/lib64/mysql/libmysqlclient.so -lz -lcrypt -lnsl -lcfitsio /IPP/ipp-2.3.lin64
lib/libfftw3f.a -L/IPPipp-2.3.lin64/lib /IPPipp-2.3.lin64/lib/libgsl.so /IPPipp-2.3.lin64/lib/libgslcblas.so -lm -ljpeg -pthread -Wl,-sona
me -Wl,libpslib.so.1 -o .libs/libpslib.so.1.0.1
/usr/lib64/gcc/x86_64-suse-linux/4.1.2/../../../../x86_64-suse-linux/bin/ld: /IPP/ipp-2.3.lin64lib/libfftw3f.a(plan-dft-r2c-1d.o): relocation R_X
86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC
/IPP/ipp-2.3.lin64lib/libfftw3f.a: could not read symbols: Bad value
collect2: ld returned 1 exit status
make[3]: * [libpslib.la] Error 1
make[3]: Leaving directory `/disk1/jester/IPP/ipp-2.3/psLib/src'
make[2]: * [all-recursive] Error 1
make[2]: Leaving directory `/disk1/jester/IPP/ipp-2.3/psLib/src'
make[1]: * [all] Error 2
make[1]: Leaving directory `/disk1/jester/IPP/ipp-2.3/psLib/src'
make: * [all-recursive] Error 1
problem building psLib : failure in make

[jester@…]

There's nothing new under the sun... this too is a known problem on 64-bit machines, as the following email from Michael explained:
​http://pan-starrs.ifa.hawaii.edu/mailman/private/ps-ipp-users/msg00176.html

The fix is that fftw3 needs to be configured with --with-pic in addition to --enable-float. So this is in fact the same category as bug 992
​http://pan-starrs.ifa.hawaii.edu/bugzilla/show_bug.cgi?id=992
just with a different (additional) flag - pschecklibs just sees that fftw3 is there, but doesn't check whether it's been compiled properly.

When libjpeg is compiled by the installer, s?he also needs to add -fPIC to the CFLAGS in the Makefile there.

[eugene]

I added the --enable-shared flags to both libjpeg and fftw3(f) when they are built by pschecklibs. Currently, pschecklibs is looking for either the .a or .so/.dylib version of the library. We may need a test to ensure the version we find supports inclusion in a shared library. does this mean we should require the .so/.dylib version?

[jhoblitt]

We don't need to require the .so version(s) of the lib(s) but the object code in either a .so or .a must be built with -fPIC. There's really no good way to find out of if the code is position independent or not except by trying to link against it. If it's not PIC, the linker will always fail on amd64 as it is required by the ABI.

[jhoblitt]

external issue; presumably dealt with

[jester@…]

Actually, it's not dealt with - I ran into this again in installing 2.6.1, as with every previous installation...

As noted above, pschecklibs at present cannot diagnose the problem, which only surfaces when psbuild tries to link against fftw3.

Thus, this is bound to confuse people who install IPP for the first time somewhere, and to re-confuse people who don't remember all the workarounds from the previous installation.

Since the automatic build system *cannot* ensure that fftw3 is built correctly on every system, I would vote to take have pschecklibs build fftw3 when installing IPP, whithout first testing whether it exists or not. That way, we'd be certain that a usable version exists.

Less work than repeating the same email or bug traffic with every new or re-install of IPP...

[jester@…]

PS: What's worse, pschecklibs doesn't actually seem to build fftw3 with -fPIC turned on? I think tagsets/ipp-2.6.1.libs needs a CFLAGS=-fPIC added to the list of configure options. But maybe not on every system?

[eugene]

we have the option here turning on 'force install' (an option in ipp-2.8.libs) or of requiring external users who encounter this problem to run pschecklibs -force (package). I suppose we should just force it so that people don't have to dig for this answer...

[eugene]

This bug is actually a psconfig question -- do we force or not the installation of our dependencies, and if so, which?