[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Guido Draheim
Subject: Re: [Mingw-users] Re: libbfd, libtool & Win32
Date: Fri, 20 Sep 2002 22:31:58 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020826

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

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

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)


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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]