Re: libbfd, libtool & Win32

[Guido Draheim]

David Olofson wrote:
> On Monday 16 September 2002 15:55, David Olofson wrote:
>
> > Reading up on libbfd right now, just to get an idea of how much, and
> > what kind of work we're talking about here.
> >
> > One question, for orientation:
> >         What's in libtool right now, and what's missing?
>
>
> Ok... After reading some old posts, it appears that the current situation 
> is basially this:
>
>         if there is an import lib; then
>                 just use the import lib
>         else
>                 build impgen    (Cross Kaboom 1: Mine dies at 'as'.)
>                 run impgen      (Cross Kaboom 2: impgen == target binary!)
>                 make an import lib out of the output
>         fi

    for each -lx -ly -lz ; do
        search trough -L specs for a .dll of that name
        // that's actually what -no-undefined does //
        if not found, choke and exit.
        else...

        if there is an gcc import lib side by side with the dll; then
                just use the gcc import lib
                    e.g. in a build with two dlls about, where one
                    needs the other, and the other has a .libs/imp
                    already there made along with the dll (it's not
                    install'ed along by default, IIRC, (!!)).
        else
                build impgen    (Cross Kaboom 1: Mine dies at 'as'.)
                    which never did break for me on either linux or solaris
                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.
        fi



> What we'd need is a install time compiled tool to replace impgen. (No 
> need to have that tool mess with the actualy import lib creation, right?)
exactly!! (a pre-build-time tool, installed along with binutils/gcc pair).

> Further, the tool should preferably be based on libbfd, instead of the 
> current raw digging-around-in-a-binary solution.
exactly!  (otherwise, it wouldn't get accepted into binutils)

> Is that correct?
aye.

> Finally, I understand there were problems actually getting the *right* 
> symbols out of a DLL, using libdfb. Does anyone know if this was because 
> of limited libbfd/PE support, or something else?

does anyone know? please, anyone, anything?