Hallo Andreas, On Jul 15, 2007, at 6:21 PM, Andreas Jellinghaus wrote:
On Saturday 14 July 2007 00:05:32 Gary V. Vaughan wrote:Another way to do it is like CVS HEAD m4: it provides a library that is in turn linked against the bundled libltdl, and all plugins must link against that library to ensure they are all calling the same libltdl.well, but if foo is compiled and installed into /opt/foo, and barinto /opt/bar, we might end up with different libltdl in both /opt/ foo/lib and /opt/bar/lib, and if some application uses both foo and bar, what willhappen again?
That will break somewhere for sure.
M4's trick is to wrap the ltdl api in its own m4_module_{,un}load calls
and tell other modules to use that.
sure, it is nice to not bother the user and not even mention libltdl, but simply include it and install it. but an honest install document will mention that foo includes and installs libltdl and mentions problems like above.
ACK. No reason to hide the fact that libltdl is under the hood, and ask module developers not to load a conflicting one.
andif the admin reads that documentation and checks the system to avoid it, then in total he might have spend more time than if the package simply said "needslibltdl, please install it first".but that is my personal guess and preference, doesn't need to be yours.
ACK 2. I was thinking that in 10 years time it might be hard to hook the
old M4 up with exactly the right release of libltdl and not have *that* ltdl conflict with the one other apps want. Hence I wrapped and shipped the particular flavour I wanted.
Thanks and regards, Andreas
Cheers,
Gary
--
())_. Email me: [EMAIL PROTECTED]
( '/ Read my blog: http://blog.azazil.net
/ )= ...and my book: http://sources.redhat.com/autobook
`(_~)_ Join my AGLOCO Network: http://www.agloco.com/r/BBBS7912
PGP.sig
Description: This is a digitally signed message part
_______________________________________________ http://lists.gnu.org/mailman/listinfo/libtool
