Re[2]: [patch] ld: PE: comprehensive auto-filtering for DLL-exportable symbols

[Paul Sokolovsky <paul-ml at is dot lg dot ua>]

Hello DJ,

DJ Delorie <dj@delorie.com> wrote on Wednesday, May 02, 2001:


>> 3. Contextual filtering by containing library name (no need to export
>>    anything coming from predefined libraries like libgcc or
>>    libstdc++).

DD> I haven't looked at the patch yet, but question: what happens if you
DD> build a dll of libgcc.a itself?

    I assume you ask in relation to the patch proposed (and not in
general; as you know, some people propose it as a solution for
threadsafe/across-module-boundaries exceptions problem).

    Ok, the idea is not to export some symbols and symbol-sets from
produced DLL. As for the latter, some symbol sets are defined on the
type of library they come from. There is no need to export anything
coming from:

1. Predefined libs which are linked into each app anyway
2. Import libs

    In whatever form libgcc comes, it fits these criteria.

    More interesting question what to do with symbols from static
libs. There seem to be no way, or even heuristics with a hint of
adequacy, to decide whether interface of static lib should be exported
from target module or not. But this problem gets clear solution on
higher, e.g. libtool, level. With libtool's world model, symbols from
"pure" static libs should not be exported, from convenience libraries
- should be.


    Of course, my patch is conservative - it filters out only symbols
which exist in almost every module and are for sure known to be a
"junk" (startup symbols) or which are dangerous to export (C++ RTTI
internal symbols).




--
Paul Sokolovsky, IT Specialist
http://www.brainbench.com/transcript.jsp?pid=11135