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