Re: Problem with libtool under HPUX: BIND_FIRST flag is required

[Ralf Wildenhues]

Hi Jan,

* Jan Giesen wrote on Sun, Nov 27, 2005 at 10:56:26PM CET:
>
> The trigger libraries are itself loaded explicitly with lt_dlopen(), but not
> in the main programm, but in a another shared library, which is implicit
> loaded from the main program.
> To access a trigger library a pointer to the GetCvsInfo function is
> requested via lt_dlsym(). The invocation of the GetCvsInfo function returns
> the pointer to the "callbacks" function call table. The programm expects
> that
> the function pointers in the call table are properly initialized by the
> share library loader; which is not the case, if "BIND_FIRST" is missing
> and it's not the first trigger library which is loaded.
> 
> Note: I can also provoke the problem under Linux using the default settings
> of Libtool 1.5.20 in ltdl.c. Since ltdl.c use by default the loader flag
> "RTLD_GLOBAL", but not "RTLD_LOCAL"

OK.  If I understand this correctly, then I can only summarize as
follows:  libltdl simply can't support this at the moment (but see
below for how you may be able to achieve a similar effect).

Long explanation:

First: technically, branch-1.5 is not ready to work from within a
library, unlike CVS HEAD.  Most things will work, but some simply
won't.  But that is not the issue here.


We need RTLD_GLOBAL by default at the moment, simply because some
libltdl users expect things to work this way.  We could add a new
interface which allows some kind of localization of symbol scope,
say lt_dlopen_mode("foo.la", LT_DL_LOCAL), but what about graceful
degradation on systems which do not allow such localization?

Consider, as an extreme, systems with static libraries only.
There, above scheme simply won't work unmodified.  However, libltdl
*can* work in the static setting if you employ the symbol prefixing
as described in the documentation and used in the libtool/mdemo/
tests:  In module foo1, use
  #define bar  foo1_LTX_bar

Granted, this isn't pretty, nor fun to debug, but it should make both
static linking work, and it should fix your issue above in the shared
linking case: lt_dlsym will look for `foo1_LTX_bar' before looking for 
`bar'.

Does this help you?  Maybe we should add a TODO item for lt_dlopen_mode.
What do the other people think?  I must admit that I don't even know
whether all other dlopening mechanisms natively allow to limit symbol
scope, nor whether such semantics are compatible.

Cheers,
Ralf