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.
_______________________________________________
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
