Hi

In building a development snapshot of one of my projects, to a custom
path, on SL6 I am running into what appears to be a linking problem.
The libtool command used to link the library is as follows:

libtool: link: gcc -std=gnu99 -shared  -fPIC -DPIC .libs/Aggregation.o
.libs/FrameCache.o .libs/FrameCalibration.o .libs/FrameData.o
.libs/FrameSeries.o .libs/FrameStream.o .libs/LALFrameIO.o
.libs/LALFrameVCSInfo.o .libs/LowLatencyData.o -Wl,-rpath
-Wl,/usr/lib64 -Wl,-rpath
-Wl,/usr1/ram/lalsuite/lal/packages/support/src/.libs -Wl,-rpath
-Wl,/usr1/ram/lalsuite/lal/lib/.libs -Wl,-rpath -Wl,/usr/lib64
-Wl,-rpath -Wl,/home/ram/lalsuite/lib64 /usr/lib64/libFrame.so
../../lal/packages/support/src/.libs/liblalsupport.so -lz
../../lal/lib/.libs/liblal.so -lgsl -lgslcblas -lfftw3 -lfftw3f -lm
-O2   -Wl,-soname -Wl,liblalframe.so.0 -o .libs/liblalframe.so.0.2.0

The problem is that there is the current release version, installed
from the release RPM, in /usr and because of the "-Wl,-rpath
-Wl,/usr/lib64" on the link line this older version is getting picked
up in preference to the more recent development version in
/home/ram/lalsuite. Why would libtool be passing /usr/lib64 to the
compiler? On Debian Squeeze, using the same git tag, the build
succeeds so I am led to believe that this is an issue with the
autotools on SL6 but I'm not sure where to start looking. Has any got
any suggestions?

Cheers

Adam

_______________________________________________
https://lists.gnu.org/mailman/listinfo/libtool

Reply via email to