Re: ld --auto-imports

["Robert Collins" <robert dot collins at itdomain dot com dot au>]

----- Original Message -----
From: "Ralf Habacker" <Ralf.Habacker@saght.tessag.com>
To: "Binutils" <binutils@sources.redhat.com>
Cc: "Paul Sokolovsky" <paul-ml@is.lg.ua>; "Robert Collins"
<robert.collins@itdomain.com.au>
Sent: Monday, June 11, 2001 5:06 PM
Subject: AW: ld --auto-imports


> Hi Robert,
>
> > Hello Robert,
> >
> > воскресенье, 10 июня 2001 г., you wrote to me:
> >
> > RC> Hi Paul,
> > RC>     You may not recognise my name - I hack on the cygwin1.dll
> > internals
> > RC> among other things. Ralf Habacker put me onto your auto-imports
> > RC> patch/hack for ld 2.11. I hope you don't mind me writing you
direct, I
> > RC> wasn't sure hwat list was appropriate. Feel free to redirect
> > me, or copy
> > RC> any reply to a list of your choice.
> >
> >     I guess binutils list is a place to discuss this, and it fact
I'd
> > appreciate such mails appearing there - likely, it won't be too easy
> > to get that patch included, so it would be nice if messages showing
> > that community reviews patch were sent there. I'm not subscribed to
> > it, however, so I'd appreciate cc: to me.
> >
> > RC> Your ld patch looks very nice, and I have a modified
libtool-HEAD here
> > RC> that using it rather than a 5 stage dllwrap process.
> >
> >     You may want to know that I did it quite some time ago, along
with
> > other useful changes. It is available at
> > http://sourceforge.net/projects/pw32/ . It worked OOB for me for
stuff
> > I tried it on (glib/gtk+ libs, for example). Ralf Habacker reported
it
> > worked ok for him with cygwin (even though package on the link above
> > built for my PW32).
> >
> > RC> I've a small bit of feedback/a question, and a more serious
question.
> >
> > RC> Firstly the feedback. I'm using a pre-compiled version from Ralf
> > RC> habacker. That version (and AFAIK it's a stock build) creates
the .dll
> > RC> base image at 0x610c0000 which collides with the cygwin1.dll.
Now the
> > RC> cygwin1.dll is theoretically relocatable, but we've just
> > found out that
> > RC> it doesn't like relocating :/. According to MSDN, the default
> > image base
>
> Why does the auto-import sample works under cygwin 1.1.8 and not under
> cygwin 1.3.2 ?
>
> > RC> for .dll's should be 0x10000000. Is there any reason your
modified ld
> > RC> couldn't set that as the default base address for .dlls? That
would
> > RC> remove the need to add --base-address=0x10000000 to the link
line in
> > RC> libtool.
> >
> >     Well:
> >
> > 1. As you understand, it is not connected with auto-import stuff in
> > any way. That's how Ralf Habacker built it.
> >
> > 2. Having specific base hardcoded is bad anyway - you'll get
> > collisions (automatically resolved, of course). Far better to
> > --enable-auto-image-base switch to ld and let it choose unique base
> > itself (based on hashing of dll name, etc.)
> >
> > 3. With my personal attitudes, ld on win32 should work as close to
> > normal unix version as possible. Mundane unix system doesn't have
any
> > idiosynacrasies around "relocatability" -
so, --enable-auto-image-base
> > should be the default as it offers most seamless solution to win32
> > strangeness. The same for --enable-auto-import . That's how I tried
to
> > do while maintaining binutild fow Mingw32. Well, new maintainer
> > doesn't share these ideas, so having that all in libtool is not
worst
> > solution ;-)
> >
> > RC> Now for the more serious question. Does your patch in theory
support
> > RC> dll's linking to other .dll's with auto-imports?
> >
> >     Of course, why not? I wouldn't claim I tested that, however.
> >
> > RC> I have a trivial hello
> > RC> world case here (built with my libtool, but I'm very sure the
symptoms
> > RC> will be the same without libtool) that segfaults _every time_.
That
> > RC> testcase has 3 source files, 2 libraries.
> > RC> hello.exe - depends on cyghello-0.dll
> > RC> cyghello-0.dll - depends on cyggreet-0.dll
> >
> > RC> cyghello-0.dll reads a string from cyggreet-0.dll, and writes it
+ ,
> > RC> World! to stdout.
>
> >
> > RC> Thanks for any suggestions you can offer. I'm happy to drop you
the
> > RC> trivial testcase, and/or prepare a non-libtool testcase that
shows the
> > RC> same symptoms - if that would help.
>
> I have provided another example with nested libs und
>
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/kde-cygwin/ld/auto-import
-nes
> ted-libs-sample/
> >
> >     Please provide one. I'd appeciate if it were not just mere
gcc/ld
> > based, but also wouldn't depend on cygwin (i.e. were built with
> > -mno-cygwin or standalone mingw).
> >
>
> There is a mistake in the makefile. Note the -lcygwin in the line
creating
> hello.dll. It must be, otherwise dll initialisation doesn*t work.

Thank you!.

I had other problems in the makefile I've just realised:
the --out-implib statements are wrong.

However it works with -lcygwin first in the link line. Do you know why
that fixes it? Maybe more symbols need to be stripped... I'll roll my
own and have a look and see why -lcygwin is needed (it's not needed with
an unaltered ld).

Rob