Re: HOST_CC for windows DLL cross-compile

[Guido Draheim]

Es schrieb Kevin Ryde:
> > But this is not
> > actually the Right Thing, dlltool should offer an option about it,
> > and since dlltool is preinstalled, we do not need to compile a
> > tool on the fly.
> 
> Yes, that'd make sense.  I suppose though that features added to
> dlltool now wouldn't actually help libtool, if it's going to continue
> to support old dlltools.
> 

Not quite. The dlltool was not part of binutils all the time - it was
developed independently, and win32 users had to install an extra package
to around with extra features for their platform. The same could be done
with impgen - let the user install it as part of a win32 tools package,
or let it be shipped along with those mingw32-complete tarballs/rpms.
This is how dlltool had been living for years being very win32-centric
and after it got merged into binutils, we have become a bit lazy-thinking
to expect that a combination of gcc and binutils (and some includes and 
other helpers) would be enough to create a valid development environment 
for a given platform. And the current hack works for years now - with 
the HOST_CC (needed for impgen.c) being a good candidate to be at the top 
of a crossgcc-win32-FAQ.

However, this is only part of the tales - dlltool is now part of the
binutils using the win32-pe routines of libbfd (!!) to read and make dlls.
On the one hand that makes sense as much of the functionality of a
dlltool to read/write win32-pe dlls has been integrated into libbfd (!!)
and it allows other tools to take advantage of it, e.g. to use dlls
as plugins on linux or something like that - the dll routines can be
reused either as libbfd.so as as copy-n-paste from its sources. On the 
other hand, there is a paramount advantage for dlltool too - it will 
ensure that a dlltool can read the very same dlls that a gcc linker can 
link. This is not the case for impgen.c - impgen does not use libbfd or 
the routines that had been developed with it for dlltool, it uses it's
own readers to access a dll export table - and this might be the case
it is hard to convince the binutils people to integrate the impgen.c
code into their package - after all, it is not related to the other
binutils code and otherwise very very specific.

There are two ways AFAICS: find someone who has some time and writing
skills to flood the binutils ML long enough to have the impgen.c code
get integrated anyway just because it is so important to win32 libtool 
and because it is in the same rank as dlltool in this respect. Or go
and rewrite impgen.c as code that uses libbfd to produce the very same
export-def ascii-file - and make sure it is identical to file we get
now. Now this may sound easy for a programmer but it needs other skills
including quite some knowledge about the inner mechanics of dll export
and import tables, which of the many ones are needed in the different
kinds of linking, how libbfd accesses them and how to use the libbfd
information to produce an export-def table that is (in its current
form) used to generate an import.lib on the fly that is usable for the 
gcc linker which uses the libbfd itself. Actually, any combination of
a script, a dllwrap-like thing, calls into a dlltool-like thing - and
that can produce an import.lib (a .a file in gnu-ld-speak) out of a
gnu-ld-produced .dll file then we would be most happy just as well.

To carve it out a bit more -  I am not even sure if there might be 
the situation that there is in fact enough functionality in the 
current win32-`objdump` and `dlltool` programs that can be used along 
with some sed calls and other scripts to produce the import-def table 
that is the result of impgen.c - and the focal point that creates
the problems we have. I just do not know and I did not take the time
to do some communications to get to know the name of someone who
could tell me by his profound knowledge of dlls and gnu-ld. May be
hang around at binutils-ml until you get the answer? Try to get a
statement of dj delorie (who has his own compiler chain)? And
what makes me wonder even more, is the fact that libtool will
create an import-lib while creating the dll itself, and all we need
is the inverse, to get an import-lib from a dll already created.

Well, in a way it is a social problem - people who do crossgcc
from unix-type platforms to win32-pe, most of them do not actually care 
about that platform enough to learn about the details of their inner
mechanics (and how gnu-ld/libbfd gets away with it). And people who
do care about the latter, they actually *work* on this platform
and they don't have the host_cc/impgen.c problem. Know a wizard
who is equally wise on all sides? Oh well... (note that I did have
a look into dlltool.c and did some play with the sources but no
acceptable result came out of it that would match the impgen.c 
result, so I did dump it after few days and call it be semihappy with
the m4-macro above that I add to any configure-script of projects
being ready-made to build as win32 too).

oops, a bit long for a small problem,
HTH, cheers,
-- guido                                    http://ac-archive.sf.net
GCS/E/S/P C++$++++ ULHS L++w- N++@ d(+-) s+a- r+@>+++ y++ 5++X-