Re: Libtool, rpath, and libGL.so
On Wed, Dec 7, 2011 at 23:26, Peter O'Gorman wrote: > Does anyone want to try again? > > http://lists.gnu.org/archive/html/libtool-patches/2010-11/msg00027.html > > I only have red hat like distros, so if someone could update the patch and > look at other distros that'd be great. I can have a play, I need to support Scientific Linux 6, Debian Squeeze, and Mac OS X (Snow Leopard and Lion) for one of my projects (one which has been hit by this problem). It may take me a while as I'm in the middle of preparing a new release of our software. Cheers Adam ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: Libtool, rpath, and libGL.so
On 11/29/2011 11:48 PM, Adam Mercer wrote: On Mon, Nov 28, 2011 at 23:30, Andy Spencer wrote: This seems to be caused by libtool adding a -rpath flag which forces the application to use the /usr/lib64 version provided by mesa even though ld.so.conf has been properly configured to use the nvidia version. I raised this question a week or so ago and the workaround suggested was to set: lt_cv_sys_lib_dlsearch_path_spec="/lib64 /usr/lib64" Does anyone want to try again? http://lists.gnu.org/archive/html/libtool-patches/2010-11/msg00027.html I only have red hat like distros, so if someone could update the patch and look at other distros that'd be great. Peter ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: Libtool, rpath, and libGL.so
On Mon, Nov 28, 2011 at 23:30, Andy Spencer wrote: > This seems to be caused by libtool adding a -rpath flag which forces the > application to use the /usr/lib64 version provided by mesa even though > ld.so.conf has been properly configured to use the nvidia version. I ran into essentially the same problem on Scientific Linux 6, essentially libtool sometimes incorrectly determines the system library paths. I imagine if you look at the sys_lib_dlsearch_path_spec variable within the libtool script it will state that /usr/lib is a system library path and not /usr/lib64. Therefore libtool will assume it needs to pass /usr/lib64 on the command line thereby leading to this linking problem. I raised this question a week or so ago and the workaround suggested was to set: lt_cv_sys_lib_dlsearch_path_spec="/lib64 /usr/lib64" during configure, this overrides the paths found by libtool and solved the linking problem for me. Unfortunately this is a hack and ignores any paths specified in ld.so.conf so you may need to tweak this accordingly. Hope this is of some help. Cheers Adam ___ https://lists.gnu.org/mailman/listinfo/libtool
Libtool, rpath, and libGL.so
I'm building a library of mine on Fedora 64-bit and running into some problems. I'm running configure as follows: ./configure --prefix=/usr --libdir=/usr/lib64 The problem is that the wrong version of libGL.so is being used at runtime. The correct version is /usr/lib64/nvidia/libGL.so.* but any application built against my library uses /usr/lib64/libGL.so.* instead. This seems to be caused by libtool adding a -rpath flag which forces the application to use the /usr/lib64 version provided by mesa even though ld.so.conf has been properly configured to use the nvidia version. I can fix the problem for other programs by manually deleting all the .la files provided by my library after I install it. However, my library also comes with a demo program which is compiled along side the library and I don't know how to make that use the correct version of libGL. Is there any way to prevent the demo program from getting build with a rpath, or are there any other ways to fix this? pgpKhH0XiIbSJ.pgp Description: PGP signature ___ https://lists.gnu.org/mailman/listinfo/libtool
