Re: ltdl weirdness

[Ralf Wildenhues]

Hello Matěj,

to add to Bob's reply:

* Bob Friesenhahn wrote on Mon, Feb 23, 2009 at 07:50:03PM CET:
> On Mon, 23 Feb 2009, Matěj Týč wrote:
>>
>> Next, if the executable is compiled with -export-dynamic, things that
>> were compiled in really provide symbols that would be missing in the
>> module. However, things that were linked in as external libs don't
>> seem to be exported. Is this expected behaviour? However, there is a
>
> Yes, this is now the expected behavior.  Older libltdl allowed libraries 
> required by loaded modules and module symbols to become part of the 
> global namespace.  As of libtool 2.2.X, this is no longer the default. 

But also, new API has been added that allows to dlopen with global
symbol visibility (which I think the above is referring to).  Quoting
NEWS:
  - New lt_dlopenadvise takes a new lt_dladvise type argument, which
    lets the caller request local or global symbol visibility from the
    module loader with lt_dladvise_local and lt_dladvise_global
    respectively.  If neither is given, or if lt_dlopen (or lt_dlopenext)
    are called, then the system default module symbol visibility is used.

See the manual for details.

>> difference between having nothing and between having linked external
>> symbols in executable compiled using -export-dynamic flag -- the first
>> case results in the inability to open the module (see the first
>> problem), whereas the latter results in runtime error.
>> Any suggestions regarding good practices?
>
> It is necessary for all symbols to be already available in the using  
> program or library, or referenced by the module as a dependency, when  
> the module is loaded.

Yes.  For portability to some (non-ELF) systems, it may even be
necessary that all module symbol references be fulfilled at module
creation time.

Hope that helps.

Cheers,
Ralf