Re[2]: ld, dlls, and windows libraries

[Paul Sokolovsky <paul-ml@is.lg.ua>]

Hello Mumit,

Mumit Khan <khan@xraylith.wisc.EDU> wrote:

MK> DJ Delorie <dj@delorie.com> writes:
>> It's in our master sources, it's all a matter of when we do the next
>> full beta.  I'm not sure about the "--export-all" part; you may need
>> to do "-Wl,--export-all" as that's a linker-specific option.  Unless
>> someone wants to get it into egcs (hint).

[]

>> 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).

  What we have now:

Dlltool can automatically make .def file from objects which are
supposed to go to dll, but that def has no DATA keyword for data, so
all by default treated as code, which in result give incorrect imlib.

  What is going to be when DJ's work's out:

Ignoring data at all.


  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).

  I'm sorry if I make incoreect implications and/or there're other
factors which make described impossible. I'd appreciate if you could
explain this or point to information about.

MK> Regards,
MK> Mumit



Best regards,
 Paul                            mailto:paul-ml@is.lg.ua