Re: [PATCH, 3/4] Enable libstdc++ as a DLL on windows platforms.

[Charles Wilson <cygwin at cwilson dot fastmail dot fm>]

Charles Wilson wrote:
> (which
> may not be much of an issue if there are no client-visible data items
> exported by that DLL [*]).
> 
> [*] Unfortunately, this is not true at present. On my system,
> cyggcc_s-1.dll has the following DATA exports:
>     __clz_tab @27 DATA
>     __popcount_tab @83 DATA
> Whether end-users are expected ever to access these two items, I don't
> know (for all I know, it may be a mistake that these two items are
> actually exposed as exports). But yea or nay, that doesn't address the
> issue of *future* data exports from libgcc_s which end users may be
> expected to access directly, and whether their declarations should be
> decorated with a macro- ("_DLL"?) controlled declspec(dllimport).

Gah. Never mind this bit. I forgot that even the auto-import of
functions generates a "single-entry import table" for each relocation,
not just data imported from DLLs.  OTOH, unlike libstdc++, client code
never accesses anything from libgcc directly (e.g. "#include some header
to get declarations, then call the function") -- any calls to libgcc
functions are inserted by the compiler itself, and it "knows what it is
doing".  So maybe my concern over /this/ issue (that is, "Third, ...")
is overblown.

--
Chuck