Re: ld, dlls, and windows libraries

[DJ Delorie <dj@delorie.com>]

> >> It's *supposed* to only export non-static functions, not non-static
> >> data.
> 
>    But what about data? There's really LOT of libraries which use data
> interface in API (most GNU libs do that too - just count: readline,
> bfd...). It would be very nice if they can be seamlessly (without
> changing source, adding defs, etc.) compiled as dll (and has correct
> implib, too).

You just can't use the --export-all function for those.  *All* data
exported by the dll *must* be tagged as __attribute__((dllimport)) or
gcc will not produce the correct code for it.  If you're tagging it
anyway, ld will notice that and export it - even without the
--export-all option.  The only time --export-all would make a
difference with data is when it turns an undefined reference into an
incorrect reference.  You'd be better off without it!

Once again: YOU MUST TELL GCC ABOUT DATA IMPORTS.  The linker can't
get it right without gcc's help, and if it has gcc's help, it doesn't
need --export-all to finish the job.

>   But what I argue is that it's possible on object file level to
> distinguish data and code and to produce correct implibs
> automatically - just because COFF symbol has code/data attribute (not
> counting that it may be inferred from the section symbol in).

True, but gcc will not use the implib correctly.  You don't understand
what gcc has to go through to access data in a dll - IT'S NOT A LINKER
PROBLEM.  Gcc has to produce *different* code depending on whether
data is local or imported - it can't use a link-time thunk like it can
for functions.  GCC MUST KNOW ABOUT IMPORTED DATA.  When it does, it
will tell the linker how to deal with it.  There is nothing the linker
can do about it, so there is no reason to provide linker-specific
options to automatically handle data.