interdependancies between libraries

/source/cvs/libtool/depdemo' (It took me awhile to notice that errors occurred, shouldn't it stop straight away? Maybe thats my fault for using CVS versions of autoconf and automake). Comments anyone? -- Brian May [EMAIL PROTECTED] ___ Libtool mailing

Re: Separate Source Directories

e upstream version also had: libvers_la_LDFLAGS = -static which meant non-PIC code was compiled in the shared libraries. I didn't like this, so removed it). -- Brian May [EMAIL PROTECTED] ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.o

Re: interdependancies between libraries

"Kevin" == Kevin Ryde [EMAIL PROTECTED] writes: On Tue, Jan 16, 2001 at 01:50:57PM +1100, Brian May wrote: Oh, another observation: installing the libraries in their non-final location (as required for Debian packaging tools, probably Redhat too) simply doe

Re: interdependancies between libraries

us libtool: install: error: relink `libl2.la' with the above command before installing it libtool: install: warning: remember to run `libtool --finish /usr/lib' [...] No, it doesn't work. -- Brian May [EMAIL PROTECTED] ___ Libtool mailing list [EMAIL

Re: interdependancies between libraries

the issue. -- Brian May [EMAIL PROTECTED] ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool

Re: interdependancies between libraries

ation path - at least this way it should work, I think?). No sense in breaking a feature on *all* platforms just because some can't cope... -- Brian May [EMAIL PROTECTED] ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool

lib*.so symlink

problem (programs designed for libz.so.1 could mistakenly use the libz.la file from libz.so.2 build). So I won't consider these problems here. Any comments? -- Brian May [EMAIL PROTECTED] ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org

Re: lib*.so symlink

on pointer to by libx.so is used? ii) when dlopening libx.la, the version pointed to by libx.so is used? -- Brian May [EMAIL PROTECTED] ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool

install phase fails

of is Linux 2.4.4 instead of 2.4.3 and glibc 2.2.3 instead of 2.2.2 ] -- Brian May [EMAIL PROTECTED] ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool

Re: install phase fails

to be created from the build directory, and it gets installed in the correct spot when the package gets installed. I imagine it will be much the same for creating RPMs, too, but I have never done that myself. Also, why did this work with libtool 1.4, but then suddenly stop working? -- Brian May [EMAIL

Re: install phase fails

Brian == Brian May [EMAIL PROTECTED] writes: Alexandre In general, when relinking is necessary, you must not Alexandre use a different prefix to install than the one used to Alexandre build. Brian In which case, you are saying that libtool is completely Brian broken

Re: install phase fails

Brian == Brian May [EMAIL PROTECTED] writes: Alexandre == Alexandre Oliva [EMAIL PROTECTED] writes: Alexandre The problem has to do with requiring relinking at Alexandre install time. This is necessary when one library in Alexandre the build tree depends on another library

Re: install phase fails

would be to replace instances of .../path/to/lib/liba.la with something like .../path/to/lib/.libs/liba.so which would be guaranteed to get the correct library. -- Brian May [EMAIL PROTECTED] ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org

Re: Search paths with duplicated .la libraries

of the library exists in /usr/lib, then that will get used instead of the library that has just been compiled. -- Brian May [EMAIL PROTECTED] ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool