[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: libbfd, libtool & Win32

From: Guido Draheim
Subject: Re: libbfd, libtool & Win32
Date: Mon, 16 Sep 2002 18:26:15 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020826

David Olofson wrote:
             run impgen (Cross Kaboom 2: impgen == target binary!)
                    where impgen will make *.dll -> *.imp.def
                make an import lib out of the output
                    by using normal dlltool/dllwrap commands
                    to turn the .def file into an implib binary
                    which is actually a staticdll format. easy part.

This is already handled in a sufficiently nice and clean way, that is?

So I say.

BTW, do any other platforms use similar import libs + DLL systems? (I hope not, but if we're going to deal with one anyway, we might as well keep them in mind, in case someone cares to add support for them...)

The win32 system setup is the most problematic, and some platforms
inherited from that (os2 and some embedded os). IIRC, that's
because some backward compatibility to dll/ne format and the
use as non-relocatable on mmu-less systems.

There might have been similar things in the unix-world, but all
unixish systems have adopted a pic-sharedlib format, mostly ELF,
over the years, with no backward compatibility. And apart from
reseach systems, unixlike systems were running on MMU hardware
since the beginning, iyam.

The next most problematic libtool format is the darwin dylib
format, where we had quite some work to do about, but that
should not quite worry you. It goes along other paths IIRC.
Should there be a need for dramatic changes in libtool, we
can look at that more closely, but I guess the major work
is not in libtool (it's done years back).

AFAIK, the current dll-handling of libtool is satisfactory
to the people around, and the remaining problems are
around impgen/implib and the problem of binding msvc dlls
with gcc dlls and vice versa. But that's an ld/libbfd
problem, it's not in the scripts.

Oh, well. I'll just play around some with libbfd, binutils and various DLLs, and see what happens. I'll also try to find some fresh documentation on PE. (MSDN at work - might find a use for it, for a change. ;-)

and try with some `dlltool -z` calls and its various command options
to extract a symbol-list from a dll, since that's what we are
using now. My guess, that there is something missing, but I do not
know which.

good luck, guido

reply via email to

[Prev in Thread] Current Thread [Next in Thread]