From: David O. <dav...@re...> - 2002-09-23 11:00:36
|
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=20 info out sees the *exact* same world as the linker - which seems to=20 suggest (to me at least) that this is definitely a job for ld. It's the=20 only tool in the chain that normally sees both the information generated=20 by the compiler (which in turn contains the data we need, extracted from=20 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=20 symbols at all... Can't rely on symbol tables, that is. (And either way,=20 it now seems that these tables only tell us what to look for; not how to=20 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=20 "official" Win32 features only. The latter seems more sane to me. If you=20 want Un*x, you don't run Windows, IMHO. If you want portability, you=20 don't develop for Un*x, but rather for an imaginary environment with a=20 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=20 application build process. ;-) //David Olofson --- Programmer, Reologica Instruments AB =2E- 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) -' =2E- M A I A -------------------------------------------------. | The Multimedia Application Integration Architecture | `----------------------------> http://www.linuxdj.com/maia -' =2E- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter | `-------------------------------------> http://olofson.net -' |