Re: wrong LD_LIBRARY_PATH in wrapper scripts

2012-11-10 Thread Poor Yorick
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

Re: wrong LD_LIBRARY_PATH in wrapper scripts

2012-11-09 Thread Poor Yorick
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

wrong LD_LIBRARY_PATH in wrapper scripts

2012-11-08 Thread Poor Yorick
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

libtool and --enable-new-dtags

2008-09-25 Thread Poor Yorick
When building software which doesn't use libtool, but does use autoconf, adding -Wl,-rpath,/path/to/lib -Wl,--enable-new-dtags is usually sufficient to end up with a shared object that has a RUNPATH value. I haven't yet figured out a good consistent way to do this with libtool. A solution that