Re: ltdl weirdness
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
ltdl weirdness
Hello all, I am using libltdl in my project and I experience some unexpected things. First of all, if I have some undefined references in my module, the module can't be loaded using lt_dlopen neither using its ext variant. The reason for that is stated as could not find the file, but this is not the case. If I correct those undefined references, everything statrts to work. BTW the 'dltest' tool had helped me, although it is a pity that it doesn't support loading symbols from executables that would load the module. 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 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? Regards, Matej ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: ltdl weirdness
On Mon, 23 Feb 2009, Matj Tý wrote: Hello all, I am using libltdl in my project and I experience some unexpected things. First of all, if I have some undefined references in my module, the module can't be loaded using lt_dlopen neither using its ext variant. The reason for that is stated as could not find the file, but this is not the case. If I correct those undefined references, everything statrts to work. BTW the 'dltest' tool had helped me, although it is a pity that it doesn't support loading symbols from executables that would load the module. This bug was reported quite some time ago and is not yet corrected. It is due to an incorrect overwrite of the error message by the module preopen code. 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. Libltdl is designed to be a module loader rather than a shared library loader. 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. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/___ http://lists.gnu.org/mailman/listinfo/libtool
