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 error reporting.
On 12/05/2011 11:48 AM, Shamis, Pavel wrote: Hi, As have been mentioned on the list, libtool error reporting - "file not found" is not perfect. People suggested to fix it (http://www.mail-archive.com/libtool@gnu.org/msg12156.html) but it seems, that the changes have never been incorporated into the trunk. I'm not well familiar with all the details of the problem, but I would suggest to improve the debug mode (-DLT_DEBUG_LOADERS) verbose messaging. Libtool already prints "Success/Failed", so I suggest to extend the message and print out the last error (LT__GETERROR(error)) for the Failed case. This seems like a good idea (if DEBUG_LOADERS is defined, print the error to stderr every time an error is set). If you don't come up with a patch, I'll try to find the time to do it. Thanks, Peter ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: Local function in shared object?
On 12/07/2011 11:45 AM, Mark R Bannister wrote: Hi, I wonder if someone could point out my error. I've defined a function, nothing special, takes a couple of args and returns a pointer to a structure. The function is not declared with any special keywords. It is not static. Yet, when compiled with gcc on Solaris and a .so target is built with libtool, the function is reported by nm as LOCAL, instead of GLOBAL. Why? Other functions in the project come out as GLOBAL. If I run nm against the .o file in .libs the function is GLOBAL. So the linker is obviously deciding when building the .so that this particular function must be LOCAL. As I'm not using the static keyword, I don't understand why this could be happening. What am I missing? Hi, How is the .so being created? Is a linker script or libtool's export symbols flags being used? Peter ___ https://lists.gnu.org/mailman/listinfo/libtool
Local function in shared object?
Hi, I wonder if someone could point out my error. I've defined a function, nothing special, takes a couple of args and returns a pointer to a structure. The function is not declared with any special keywords. It is not static. Yet, when compiled with gcc on Solaris and a .so target is built with libtool, the function is reported by nm as LOCAL, instead of GLOBAL. Why? Other functions in the project come out as GLOBAL. If I run nm against the .o file in .libs the function is GLOBAL. So the linker is obviously deciding when building the .so that this particular function must be LOCAL. As I'm not using the static keyword, I don't understand why this could be happening. What am I missing? Thanks, Mark. Sent from my HTC___ https://lists.gnu.org/mailman/listinfo/libtool
