On Mon, 25 Jul 2005, Owen Taylor wrote: > -export-symbols is pretty straightforward to use - we use it (or > actually, -export-symbols-regex for Pango). You probably could build > the symbol file pretty easily by scanning the for FT_EXPORT ... > well, if you didn't use that for internal symbols.
Ulrich Drepper writes in his paper [1]: =================== 2.2.6 Libtool's -export-symbols ... Interesting for us here is the code the linker produces using this method. For the GNU linker Libtool converts -export-symbols option into the completely useless -retain-symbols-file option. This option instructs the linker to prune the normal symbol tables, not the dynamic symbol table. The normal symbol table will contain only the symbols named in the export list file plus the special STT_SECTION symbols which might be needed in relocations. All local symbols are gone. The problem is that the dynamic symbol table is not touched at all and this is the table which is actually used at runtime. The effect of the using libtool this way is that programs reading the normal symbol table (for instance nm) do not find any symbols but those listed in the export list. Neither have any symbols been made unavailable for the dynamic linker, nor have any normal relocations been converted into relative relocations. The only reason this method is mentioned here is that there is hope libtool will learn about converting the export lists into the anonymous version maps we have seen in the previous section when the GNU linker is used. At that point libtool will become useful. Until then relying on its -export-symbols option is misleading at best. ====================== Don't know if this has changed since. A quick look at the libtool ChangeLog doesn't suggest any. CC'ing [EMAIL PROTECTED] [1] http://www.livejournal.com/users/udrepper/2491.html --behdad http://behdad.org/ _______________________________________________ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel