Re: Trouble controlling linking if many library versions areinstalled

op-flags, or perhaps better, --begin-group --end-group as someone recently mentioned, but that's not going to help on all architectures... -- Rob Browning rlb @defaultvalue.org, @linuxdevel.com, and @debian.org Previously @cs.utexas.edu GPG=1C58 8B2C FB5E 3F6

Re: Buffer overruns in libltdl/ltdl.c

- it was causing all manner of problems here. Why does ltdl need to implement its own memory management anyway? -- Rob Browning rlb @defaultvalue.org, @linuxdevel.com, and @debian.org Previously @cs.utexas.edu GPG=1C58 8B2C FB5E 3F64 EA5C 64AE 78FE E5FE F0CB A0AD ___

Re: Trouble controlling linking if many library versions areinstalled

to /opt/guile-1.5, you will be unable to compile or link a gtk app against guile 1.5 if any of the gtk config scripts output -L/usr/lib and those flags appear before -lguile on the link line. On Linux and similar systems, could libtool, foo-config scripts, etc. just special case (and omit) -L/usr/

Re: stopping relinking under elf/linux

e ... install or similar. Hope this helps. -- Rob Browning rlb @defaultvalue.org, @linuxdevel.com, and @debian.org Previously @cs.utexas.edu GPG=1C58 8B2C FB5E 3F64 EA5C 64AE 78FE E5FE F0CB A0AD ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool

Re: Hack for inter-library dependency (make DESTDIR=... install)problem.

Rob Browning <[EMAIL PROTECTED]> writes: > Agreed -- the same is true with Debian -- minimizing the Debian diff > is a good idea, all other things being equal. In any case, thanks > so much. I'll try this -- it looks like a good solution. That appeared to work perfe

Re: Hack for inter-library dependency (make DESTDIR=... install)problem.

s true with Debian -- minimizing the Debian diff is a good idea, all other things being equal. In any case, thanks so much. I'll try this -- it looks like a good solution. -- Rob Browning rlb @defaultvalue.org, @linuxdevel.com, and @debian.org Previou

Re: Hack for inter-library dependency (make DESTDIR=... install)problem.

libfoo) and not worry about the fact that the library's eventually going to be in /usr/lib... I'm curious about your suggestion because the hack I'm using right now is causing problems, and I'm going to have to come up with something better. I've even thought of

Allowing guile to open a lib satisfying a given interface.

look at the source and perform some tests, but this seems like it might solve our problems, and if it does work, then perhaps some variation on this approach might be acceptable to the libtool maintainers. Thoughts? -- Rob Browning rlb @defaultvalue.org, @linuxdevel.com, and @debian.org Previously

Re: Hack for inter-library dependency (make DESTDIR=... install)problem.

cking around with the Makefiles. Agreed, but for me right now, it's better than nothing, and I needed *some* fix to allow some needed inter-lib dependencies to be included in the 1.4 packages. -- Rob Browning rlb @defaultvalue.org, @linuxdevel.com, and @debian.org Previously @cs.utexas.edu GP

Hack for inter-library dependency (make DESTDIR=... install)problem.

s a better suggestion, I'd be happy to hear it. Hope this helps. -- Rob Browning rlb @defaultvalue.org, @linuxdevel.com, and @debian.org Previously @cs.utexas.edu GPG=1C58 8B2C FB5E 3F64 EA5C 64AE 78FE E5FE F0CB A0AD ___ Libtool mailing list [EMAIL

Re: What about adding lt_dlopen_interface(lib, number)?

Rob Browning <[EMAIL PROTECTED]> writes: > How would people feel about the addition of a new function > > lt_dlhandle lt_dlopen_interface(const char *name, int interface_number); So do the libtool maintainers have any opinion about this one way or the other? As it stand

Re: libtool doesn't allow "make DESTDIR=`pwd`/foo install" anymore.

) so that we don't regress in the future. -- Rob Browning rlb @defaultvalue.org, @linuxdevel.com, and @debian.org Previously @cs.utexas.edu GPG=1C58 8B2C FB5E 3F64 EA5C 64AE 78FE E5FE F0CB A0AD ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool

Re: libtool doesn't allow "make DESTDIR=`pwd`/foo install" anymore.

libguile_la_LIBADD = @LIBLOBJS@ $(LIBLTDL) $(THREAD_LIBS_LOCAL) libguile_la_LDFLAGS = -version-info @LIBGUILE_INTERFACE_CURRENT@:@LIBGUILE_INTERFACE_REVISION@:@LIBGUILE_INTERFACE_AGE@ -export-dynamic -no-undefined where $(THREAD_LIBS_LOCAL) := ../qt/libqthreads.la -- Rob Browning rlb @defau

libtool doesn't allow "make DESTDIR=`pwd`/foo install" anymore.

an package that seems to fix the problem for some people, but still doesn't work for other package like guile and heimdal. Thanks -- Rob Browning rlb @defaultvalue.org, @linuxdevel.com, and @debian.org Previously @cs.utexas.edu GPG=1C58 8B2C FB5E 3F64 EA5C 64AE

Re: use of libtool for linking executables - rpath problem

e the foo 1.1 version in /usr/lib. Now you can get around this by changing the order above, but that won't scale, and breaks if the situation wrt foo and gnome were reversed. -- Rob Browning rlb @defaultvalue.org, @linuxdevel.com, and @debian.org Previously @cs.utexas.edu GP

Re: use of libtool for linking executables - rpath problem

e compile line. But though I've had some agreement from relevant developers, I wouldn't expect to see this any time soon. -- Rob Browning rlb @defaultvalue.org, @linuxdevel.com, and @debian.org Previously @cs.utexas.edu GPG=1C58 8B2C FB5

What about adding lt_dlopen_interface(lib, number)?

tool seems likely to involve fairly awkward library filesystem placement, and LD_LIBRARY_PATH tricks. If people think this is a good idea, I'd be happy to help write the code. Thanks -- Rob Browning rlb @defaultvalue.org, @linuxdevel.com, and @debian.org Previously @cs.utexas.edu GPG=1C58

Re: duplicate dependencies [was: RE: Very slow links: > 1 hour tolin k single executable - can we help?]

mean time, anyone care to suggest what the flag > should be? --preserve-dup-deps ??? As another data point. I we installed your ltmain.sh in gnucash and link times on a 1Ghz athlon went from two hours to ten minutes, and everything still seems to work OK. Thanks. -- Rob Browning rlb @defau

A hack we've been using -- is this OK, or likely to fail?

_la_LIBADD = -L../somedir -L../somedir/.libs -lbar This has made me a little nervous, so I wanted to check to see if this is likely to work OK, either under 1.4.2 or prior versions, or if this could be expected to cause trouble. Thanks -- Rob Browning rlb @defaultvalue.org, @linuxdeve

Very slow links: > 1 hour to link single executable - can we help?

ther_flags $i" ;; # add it to output esac ;; esac done ord_libs= if $libs_l; then for i in $rev_libs; do case " $ord_libs " in *\ $i\ *) ;;# already there *) ord_libs="$i $ord_libs" ;; # add it to output in