Re: normal ltdl linking suggestions?

[Andreas Jellinghaus]

On Saturday 14 July 2007 00:05:32 Gary V. Vaughan wrote:
> It won't work on at least several platforms... possibly not on any
> platform.
> Certainly duplicate symbols from different versions of the same
> library will
> cause runtime problems even if the linker doesn't raise a red flag.

ok, thanks. I guess that using a shared library and suggesting
noone links in the same code as static code or otherwise is the
best way. might not work on all plattform, but the ABI in question might be 
not specified with all plattforms (or the plattform might miss some feature 
needed to implement it).

> 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 bar 
into /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 will 
happen again?

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. and 
if 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 "needs 
libltdl, please install it first".

but that is my personal guess and preference, doesn't need to be yours.

Thanks and regards, Andreas


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: normal ltdl linking suggestions?

[Gary V. Vaughan]

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 bar
into /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 will

happen 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.


and
if 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 "needs

libltdl, 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