Re: linking problems on SL6
On 11/22/2011 11:36 PM, Adam Mercer wrote: On Mon, Nov 21, 2011 at 15:39, Peter O'Gormanpe...@pogma.com wrote: Glad it works around it. The problem is libtool brokenness, most vendors patch around it in their packaged libtool, e.g. http://pkgs.fedoraproject.org/gitweb/?p=libtool.git;a=blob;f=libtool-2.2.10-rpath.patch;h=d0d6d82178642658e6aca5a28d36813158980ca3;hb=HEAD Is there any reason something like this isn't done in the source so vendors don't have to patch? Apart from it being a hack that is :-) I'm not sure if we ever looked for what distros use what layout for multilibs, and how to detect them. There was a patch somewere which was slow, but ended up correct, using ldconfig. I'll look for it again. Peter ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: linking problems on SL6
On Wed, Nov 23, 2011 at 08:52, Peter O'Gorman pe...@pogma.com wrote: I'm not sure if we ever looked for what distros use what layout for multilibs, and how to detect them. There was a patch somewere which was slow, but ended up correct, using ldconfig. I'll look for it again. Thanks, let me know if I can help with anything. Cheers Adam ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: linking problems on SL6
On Mon, Nov 21, 2011 at 15:39, Peter O'Gorman pe...@pogma.com wrote: Glad it works around it. The problem is libtool brokenness, most vendors patch around it in their packaged libtool, e.g. http://pkgs.fedoraproject.org/gitweb/?p=libtool.git;a=blob;f=libtool-2.2.10-rpath.patch;h=d0d6d82178642658e6aca5a28d36813158980ca3;hb=HEAD Is there any reason something like this isn't done in the source so vendors don't have to patch? Apart from it being a hack that is :-) Cheers Adam ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: linking problems on SL6
Hi, On 11/19/2011 01:03 AM, Adam Mercer wrote: 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 Are these -Wl,-rpath flags coming from libtool? They seem to be there already on the libtool command line. Could you post this snippet of your makefile.am, please? 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? Libtool has issues with multilib systems. Someone had a patch at some point that correctly figured out the multilib library paths using ldconfig, but I've long forgotten who. You can set lt_cv_sys_lib_dlsearch_path_spec and lt_cv_sys_lib_search_path_spec at configure time if libtool is getting sys_lib_dlsearch_path_spec/sys_lib_search_path_spec wrong (check the generated libtool script for ^sys_lib_dlsearch_path_spec and ^sys_lib_search_path_spec to see what it's guessing). Debian/Red Hat systems do multilib differently, one has lib32 and lib, the other lib and lib64, I wouldn't be surprised if someone has a linux system with lib32 lib and lib64 (like IRIX!). Peter ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: linking problems on SL6
On Mon, Nov 21, 2011 at 12:21, Peter O'Gorman pe...@pogma.com wrote: Peter Are these -Wl,-rpath flags coming from libtool? They seem to be there already on the libtool command line. Could you post this snippet of your makefile.am, please? I am not setting these myself and they don't seem to be coming from any library dependencies. The section of the Makefile.am that deals with the library is essentially: INCLUDES = -I$(top_builddir)/include LDADD = liblalframe.la lalframeincludedir = $(includedir)/lal lalframeinclude_HEADERS = \ Aggregation.h \ FrameCache.h \ FrameCalibration.h \ FrameData.h \ FrameStream.h \ LALFrameConfig.h \ LALFrameIO.h \ LALFrameL.h \ LALFrameVCSInfo.h \ LowLatencyData.h lib_LTLIBRARIES = liblalframe.la liblalframe_la_SOURCES = \ Aggregation.c \ FrameCache.c \ FrameCalibration.c \ FrameData.c \ FrameSeries.c \ FrameStream.c \ LALFrameIO.c \ LALFrameVCSInfo.c \ LowLatencyData.c noinst_HEADERS = \ FrameSeriesRead_source.c \ FrameSeriesWrite_source.c liblalframe_la_LDFLAGS = -version-info $(LIBVERSION) This is not the complete Makefile.am, the rest is stuff for test codes, documentation, etc... Libtool has issues with multilib systems. Someone had a patch at some point that correctly figured out the multilib library paths using ldconfig, but I've long forgotten who. You can set lt_cv_sys_lib_dlsearch_path_spec and lt_cv_sys_lib_search_path_spec at configure time if libtool is getting sys_lib_dlsearch_path_spec/sys_lib_search_path_spec wrong (check the generated libtool script for ^sys_lib_dlsearch_path_spec and ^sys_lib_search_path_spec to see what it's guessing). I have been looking at those variables, they are set as: # Compile-time system search path for libraries. sys_lib_search_path_spec=/usr/lib/gcc/x86_64-redhat-linux/4.4.5 /usr/lib64 /lib64 # Run-time system search path for libraries. sys_lib_dlsearch_path_spec=/lib /usr/lib /usr/lib64/R/lib /usr/lib/atlas-3dnow /usr/lib/atlas-sse /usr/lib/atlas-sse2 /usr/lib/atlas-sse3 /usr/lib64/atlas /usr/lib64/mysql /usr/lib64/octave-3.2.4 /usr/lib64/root sys_lib_search_path_spec seems to be what I'd expect, but not sys_lib_dlsearch_path_spec. If I edit this to contain /lib64 and /usr/lib64 then the -Wl,-rpath -Wl,/usr/lib64 flags aren't passed and the library links correctly. I've been looking through libtool.m4, specifically where is sets sys_lib_dlsearch_path_spec, and the output seems to be correct given the code but I'm not very familier with the libtool internals so I could be mistaken. Setting lt_cv_sys_lib_dlsearch_path_spec=/lib64 /usr/lib64 at configure time results in -Wl,-rpath -Wl,/usr/lib64 not being passed and the correct libraries linked. So this is a workaround but I'd like to understand why these flags are being added in the first place. Cheers Adam ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: linking problems on SL6
On 11/21/2011 03:22 PM, Adam Mercer wrote: Setting lt_cv_sys_lib_dlsearch_path_spec=/lib64 /usr/lib64 at configure time results in -Wl,-rpath -Wl,/usr/lib64 not being passed and the correct libraries linked. So this is a workaround but I'd like to understand why these flags are being added in the first place. Glad it works around it. The problem is libtool brokenness, most vendors patch around it in their packaged libtool, e.g. http://pkgs.fedoraproject.org/gitweb/?p=libtool.git;a=blob;f=libtool-2.2.10-rpath.patch;h=d0d6d82178642658e6aca5a28d36813158980ca3;hb=HEAD Peter ___ https://lists.gnu.org/mailman/listinfo/libtool
linking problems on SL6
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
