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

[David Olofson]

On Friday 20 September 2002 22:31, Guido Draheim wrote:
> David Olofson wrote:
[...]
> > 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.

Yeah, but of course, you'll have to make sure that whatever digs that 
info out sees the *exact* same world as the linker - which seems to 
suggest (to me at least) that this is definitely a job for ld. It's the 
only tool in the chain that normally sees both the information generated 
by the compiler (which in turn contains the data we need, extracted from 
the headers that belong to the DLLs), and the actual DLLs.


> In
> fact, we have a set of function names for a given lib - in its
> symbol table.

In an export table, I would say, as most clean Win32 DLLs don't export 
symbols at all... Can't rely on symbol tables, that is. (And either way, 
it now seems that these tables only tell us what to look for; not how to 
use it... :-/ )



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

Right. Either we emulate Un*x on Win32, or we have our tools support 
"official" Win32 features only. The latter seems more sane to me. If you 
want Un*x, you don't run Windows, IMHO. If you want portability, you 
don't develop for Un*x, but rather for an imaginary environment with a 
feature set that's available on all platforms you're interested in.


However, it's still a very bad idea to compile tools as part of the 
application build process. ;-)


//David Olofson --- Programmer, Reologica Instruments AB

.- Coming soon from VaporWare Inc...------------------------.
| The Return of Audiality! Real, working software. Really!  |
| Real time and off-line synthesis, scripting, MIDI, LGPL...|
`-----------------------------------> (Public Release RSN) -'
.- M A I A -------------------------------------------------.
|    The Multimedia Application Integration Architecture    |
`----------------------------> http://www.linuxdj.com/maia -'
.- David Olofson -------------------------------------------.
| Audio Hacker - Open Source Advocate - Singer - Songwriter |
`-------------------------------------> http://olofson.net -'