Re: wrong LD_LIBRARY_PATH in wrapper scripts
On Sat, Nov 10, 2012 at 11:28 AM, Poor Yorick
org.gnu.lists.libt...@pooryorick.com wrote:
On Nov 8, 2012 6:38 PM, Poor Yorick
org.gnu.lists.libt...@pooryorick.com
[SNIP]
the culprit turns out to be /path/to/software/collection/lib/libffi.la,
which was included in dependency_libs of
/path/to/src/glib-2.32.4/glib-2.32.4/gobject/libgobject-2.0.la. If I remove
that, the error disappears.
Here's a libtool command
(pwd=/path/to/src/glib-2.32.4/glib-2.32.4/gobject/libgobject/tests) that
creates a wrapper with the bad LD_LIBRARY_PATH:
../../libtool --tag=CC --mode=link gcc -m64 -g -O2 -Wall
-L/path/to/src/glib-2.32.4/glib-2.32.4/glib/.libs -o boxed boxed.o
../libgobject-2.0.la ../../gthread/libgthread-2.0.la
../../glib/libglib-2.0.la
Now the question is how to systematically work around such problems? Editing
any of the .la files doesn't seem right. Is there something I can add to my
build environment or configuration options?
I tried various things to try to get libtool to do the right thing, but
finally
just made a symylink to libffi
/path/to/src/glib-2.32.4/glib-2.32.4/glib/.libs,
which convinced libtool not to add /path/to/software/collection/lib to the
LD_LIBRARY_PATH in the wrappers scripts. I wish I could have found a less
ughly hack, or even a good fix.
Ref: http://bugzilla.gnome.org/show_bug.cgi?id=688054
I'm pretty sure this is not a bug in glib, but just a tricky libtool
bug. glib is simply telling libtool that it wants to link a program
against its 3 in-tree libraries, and the hard part is that not all of
the in-tree libraries need to link to installed libraries. libtool is
appropriately figuring out which installed libraries are needed and
making an almost correct LD_LIBRARY_PATH so that you don't have to
fiddle with anything to run the program. What libtool could do is take
it's calculated portion of the path and sort it so that any paths that
are within the build directory come first. Something like this (I
haven't looked at libtool):
for path in `IFS=: echo $computed_library_path`; do
case $path in
$builddir/*) pre_path=${pre_path+$pre_path:}$path ;;
*) post_path=${post_path+$post_path:}$path ;;
esac
done
LD_LIBRARY_PATH=${pre_path+$pre_path:}${post_path+$post_path:}$LD_LIBRARY_PATH
--
Dan
___
https://lists.gnu.org/mailman/listinfo/libtool
Re: wrong LD_LIBRARY_PATH in wrapper scripts
On Nov 8, 2012 6:38 PM, Poor Yorick org.gnu.lists.libt...@pooryorick.com [SNIP] the culprit turns out to be /path/to/software/collection/lib/libffi.la, which was included in dependency_libs of /path/to/src/glib-2.32.4/glib-2.32.4/gobject/libgobject-2.0.la. If I remove that, the error disappears. Here's a libtool command (pwd=/path/to/src/glib-2.32.4/glib-2.32.4/gobject/libgobject/tests) that creates a wrapper with the bad LD_LIBRARY_PATH: ../../libtool --tag=CC --mode=link gcc -m64 -g -O2 -Wall -L/path/to/src/glib-2.32.4/glib-2.32.4/glib/.libs -o boxed boxed.o ../libgobject-2.0.la ../../gthread/libgthread-2.0.la ../../glib/libglib-2.0.la Now the question is how to systematically work around such problems? Editing any of the .la files doesn't seem right. Is there something I can add to my build environment or configuration options? I tried various things to try to get libtool to do the right thing, but finally just made a symylink to libffi /path/to/src/glib-2.32.4/glib-2.32.4/glib/.libs, which convinced libtool not to add /path/to/software/collection/lib to the LD_LIBRARY_PATH in the wrappers scripts. I wish I could have found a less ughly hack, or even a good fix. Ref: http://bugzilla.gnome.org/show_bug.cgi?id=688054 -- Yorick ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: wrong LD_LIBRARY_PATH in wrapper scripts
On Nov 8, 2012 6:38 PM, Poor Yorick org.gnu.lists.libt...@pooryorick.com wrote: Hi, Attempting to build glib-2.32.4, the make check stage, produces this result: /path/to/src/glib-2.32.4/glib-2.32.4/gobject/tests/.libs/boxed: symbol lookup error: /path/to/glib-2.32.4/glib-2.32.4/gobject/.libs/libgobject-2.0.so.0: undefined symbol: g_key_file_unref looking at .../gobject/test/boxed, which is a libtoolw wrapper, I see LD_LIBRARY_PATH=/path/to/src/glib-2.32.4/glib-2.32.4/gobject/.libs:/path/to/src/glib-2.32.4/glib-2.32.4/gthread/.libs:/path/to/software/collection/lib:/path/to/src/glib-2.32.4/glib-2.32.4/glib/.libs:$LD_LIBRARY_PATH The problem here is that /path/to/software/collection/lib comes prior to /path/to/src/glib-2.32.4/glib-2.32.4/glib/.libs, so the runtime linker is picking up /path/co/software/collection/lib/libglib-2.0.so instead of /path/to/src/glib-2.32.4/glib-2.32.4/glib/.libs/libglib-2.0.so. I presume that libtool inserted all three of the .libs paths, but don't see why it inserted two of them before /path/to/software/collection/lib, and one after. .../gobject/tests/Makefile has this: boxed_DEPENDENCIES = ../libgobject-2.0.la \ $(top_builddir)/gthread/libgthread-2.0.la \ $(top_builddir)/glib/libglib-2.0.la /path/to/software/collection/lib exists both in the configuring environments LD_LIBRARY_PATH variable, as well as in the LDFLAGS variable. I've tried prepending -L/path/to/src/glib-2.32.4/glib-2.32.4/glib/.libs to the LDFLAGS variable, with the same results. If I had to guess, one of gthread's dependencies is in /path/to/software/collection/lib, so libtool adds it when processing libgthread.la. On the other hand, I think both gobject and gthread depend on glib, so I'd expect libtool to add its srcdir path at the appropriate spot. You may want to look at the deplibs in the .la files to see if that's the case. Maybe attach all three .la files. Dan ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: wrong LD_LIBRARY_PATH in wrapper scripts
On Fri, Nov 09, 2012 at 07:12:10AM -0800, Dan Nicholson wrote: On Nov 8, 2012 6:38 PM, Poor Yorick org.gnu.lists.libt...@pooryorick.com wrote: Hi, Attempting to build glib-2.32.4, the make check stage, produces this result: /path/to/src/glib-2.32.4/glib-2.32.4/gobject/tests/.libs/boxed: symbol lookup error: /path/to/glib-2.32.4/glib-2.32.4/gobject/.libs/libgobject-2.0.so.0: undefined symbol: g_key_file_unref looking at .../gobject/test/boxed, which is a libtoolw wrapper, I see LD_LIBRARY_PATH=/path/to/src/glib-2.32.4/glib-2.32.4/gobject/.libs:/path/to/src/glib-2.32.4/glib-2.32.4/gthread/.libs:/path/to/software/collection/lib:/path/to/src/glib-2.32.4/glib-2.32.4/glib/.libs:$LD_LIBRARY_PATH The problem here is that /path/to/software/collection/lib comes prior to /path/to/src/glib-2.32.4/glib-2.32.4/glib/.libs, so the runtime linker is picking up /path/co/software/collection/lib/libglib-2.0.so instead of /path/to/src/glib-2.32.4/glib-2.32.4/glib/.libs/libglib-2.0.so. I presume that libtool inserted all three of the .libs paths, but don't see why it inserted two of them before /path/to/software/collection/lib, and one after. .../gobject/tests/Makefile has this: boxed_DEPENDENCIES = ../libgobject-2.0.la \ $(top_builddir)/gthread/libgthread-2.0.la \ $(top_builddir)/glib/libglib-2.0.la /path/to/software/collection/lib exists both in the configuring environments LD_LIBRARY_PATH variable, as well as in the LDFLAGS variable. I've tried prepending -L/path/to/src/glib-2.32.4/glib-2.32.4/glib/.libs to the LDFLAGS variable, with the same results. If I had to guess, one of gthread's dependencies is in /path/to/software/collection/lib, so libtool adds it when processing libgthread.la. On the other hand, I think both gobject and gthread depend on glib, so I'd expect libtool to add its srcdir path at the appropriate spot. You may want to look at the deplibs in the .la files to see if that's the case. Maybe attach all three .la files. the culprit turns out to be /path/to/software/collection/lib/libffi.la, which was included in dependency_libs of /path/to/src/glib-2.32.4/glib-2.32.4/gobject/libgobject-2.0.la. If I remove that, the error disappears. Here's a libtool command (pwd=/path/to/src/glib-2.32.4/glib-2.32.4/gobject/libgobject/tests) that creates a wrapper with the bad LD_LIBRARY_PATH: ../../libtool --tag=CC --mode=link gcc -m64 -g -O2 -Wall -L/path/to/src/glib-2.32.4/glib-2.32.4/glib/.libs -o boxed boxed.o ../libgobject-2.0.la ../../gthread/libgthread-2.0.la ../../glib/libglib-2.0.la Now the question is how to systematically work around such problems? Editing any of the .la files doesn't seem right. Is there something I can add to my build environment or configuration options? -- Yorick ___ https://lists.gnu.org/mailman/listinfo/libtool
wrong LD_LIBRARY_PATH in wrapper scripts
Hi, Attempting to build glib-2.32.4, the make check stage, produces this result: /path/to/src/glib-2.32.4/glib-2.32.4/gobject/tests/.libs/boxed: symbol lookup error: /path/to/glib-2.32.4/glib-2.32.4/gobject/.libs/libgobject-2.0.so.0: undefined symbol: g_key_file_unref looking at .../gobject/test/boxed, which is a libtoolw wrapper, I see LD_LIBRARY_PATH=/path/to/src/glib-2.32.4/glib-2.32.4/gobject/.libs:/path/to/src/glib-2.32.4/glib-2.32.4/gthread/.libs:/path/to/software/collection/lib:/path/to/src/glib-2.32.4/glib-2.32.4/glib/.libs:$LD_LIBRARY_PATH The problem here is that /path/to/software/collection/lib comes prior to /path/to/src/glib-2.32.4/glib-2.32.4/glib/.libs, so the runtime linker is picking up /path/co/software/collection/lib/libglib-2.0.so instead of /path/to/src/glib-2.32.4/glib-2.32.4/glib/.libs/libglib-2.0.so. I presume that libtool inserted all three of the .libs paths, but don't see why it inserted two of them before /path/to/software/collection/lib, and one after. .../gobject/tests/Makefile has this: boxed_DEPENDENCIES = ../libgobject-2.0.la \ $(top_builddir)/gthread/libgthread-2.0.la \ $(top_builddir)/glib/libglib-2.0.la /path/to/software/collection/lib exists both in the configuring environments LD_LIBRARY_PATH variable, as well as in the LDFLAGS variable. I've tried prepending -L/path/to/src/glib-2.32.4/glib-2.32.4/glib/.libs to the LDFLAGS variable, with the same results. I'm asking on this list rather than the glib list because I'd like to understand in general what the issue might be and how to use libtool correctly in order not to have this kind of issue. How should I go about making sure that /path/to/src/glib-2.32.4/glib-2.32.4/glib/.libs has the proper precedence in LD_LIBRARY_PATH in the wrapper scripts? -- Yorick ___ https://lists.gnu.org/mailman/listinfo/libtool
