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
_______________________________________________
http://lists.gnu.org/mailman/listinfo/libtool
