[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Mingw-users] Re: libbfd, libtool & Win32
From: |
David Olofson |
Subject: |
Re: [Mingw-users] Re: libbfd, libtool & Win32 |
Date: |
Mon, 23 Sep 2002 13:00:23 +0200 |
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 -'
- Re: [Mingw-users] Re: libbfd, libtool & Win32, (continued)
- Re: [Mingw-users] Re: libbfd, libtool & Win32, David Olofson, 2002/09/18
- Re: [Mingw-users] Re: libbfd, libtool & Win32, David Olofson, 2002/09/18
- Re: [Mingw-users] Re: libbfd, libtool & Win32, Danny Smith, 2002/09/18
- Re: [Mingw-users] Re: libbfd, libtool & Win32, David Olofson, 2002/09/18
- Re: [Mingw-users] Re: libbfd, libtool & Win32, Danny Smith, 2002/09/18
- Re: [Mingw-users] Re: libbfd, libtool & Win32, David Olofson, 2002/09/18
- Re: [Mingw-users] Re: libbfd, libtool & Win32, Danny Smith, 2002/09/18
- Re: [Mingw-users] Re: libbfd, libtool & Win32, David Olofson, 2002/09/20
- Re: [Mingw-users] Re: libbfd, libtool & Win32, Guido Draheim, 2002/09/20
- Re: [Mingw-users] Re: libbfd, libtool & Win32, Earnie Boyd, 2002/09/20
- Re: [Mingw-users] Re: libbfd, libtool & Win32,
David Olofson <=
- Re: [Mingw-users] Re: libbfd, libtool & Win32, David Olofson, 2002/09/23
- Re: [Mingw-users] Re: libbfd, libtool & Win32, Earnie Boyd, 2002/09/23
- Re: [Mingw-users] Re: libbfd, libtool & Win32, David Olofson, 2002/09/23
- Re: [Mingw-users] Re: libbfd, libtool & Win32, Earnie Boyd, 2002/09/23
- Re: [Mingw-users] Re: libbfd, libtool & Win32, Earnie Boyd, 2002/09/16
- Re: [Mingw-users] Re: libbfd, libtool & Win32, Max Bowsher, 2002/09/17
- Re: [Mingw-users] Re: libbfd, libtool & Win32, Guido Draheim, 2002/09/17
- "Re: libbfd, libtool & Win32" and "Re: Building a MinGW GLib etc...", Max Bowsher, 2002/09/16
- Re: "Re: libbfd, libtool & Win32" and "Re: Building a MinGW GLib etc...", Robert Boehne, 2002/09/16
- Re: "Re: libbfd, libtool & Win32" and "Re: Building a MinGW GLib etc...", Max Bowsher, 2002/09/16