Re: [Mingw-users] Re: libbfd, libtool & Win32

[Guido Draheim]

David Olofson wrote:
> On Wednesday 18 September 2002 22:37, Danny Smith wrote:
> [...]
>
>
> > > or does that mean we
> > > either have to make assumptions, or just *require* import libs to be
> > > present?
> >
> > The latter is certainly safer.
>
>
> Yeah, but it doesn't work if you can't get an import lib that works with 
> your compiler...

that's the stateofart in the windows world - if you have another
compiler that the given importlib is not compatible with then
you will be forced to run implib.exe in a seperate step. That's
what our impgen is all about - doing that automatically since
unix software does not need such bu**s**t of compiler-specific
importlibs.

> How about building import libs from headers? (You need the headers to 
> compile anyway...)

Ahhm, not quite - some functions are exported only on a case-by-case
basis, and there are quite some different ways to get at the CFLAGS
needed for that. And you can play some catchme with distributing
functions across a number of headers and a number of libraries. In
fact, we have a set of function names for a given lib - in its
symbol table.

> > You also need to consider DATA symbols,
> > and the special tricks required to import data, particularly  arrays
> > and structs, using --enable-auto--import.   The extensions to
> > --enable-auto-import for  arrays and structs (Egor Duda's work )
> > require both binutils support (a modified linker script, for a start)
> > and runtime support (in the pipe for cygwin, not for mingw)
>
>
> Ouch.
>
> Well, as far as my projects are concerned, I consider exporting anything 
> but functions non-portable, and usually a bad idea for other reasons. 
> Would be nice if it could be made to work somehow, but I probably won't 
> make use of that feature myself.

Just my point. It's nice that cygwin wants to emulate the unix behaviour
to a degree that even data-symbols are im/exported in the usual manner,
that's different with mingw-software where I do take the burden to make
it ready to run in crippled environment, just to make it more "native".
That's the whole point of it anyway... and therefore, making software
windows-ready means to look for the difference in datasymbol export (and
to not use them, actually). I won't make use of that cygwin feature
since I know of problems with compiling the dll sources with msvc and
borland and watcom - and I am quite sure they don't have the same scheme
of wrapping the unixish stuff in DLLs, like exported data symbols.