This is the mail archive of the binutils@sources.redhat.com mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

AW: ld --auto-imports


>
> ----- 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.
>
I have tried to mark this with ^^^^, but there are tabs in my mail, so they
don't fit the correct columns.

> 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).
The reason is, that hello.dll uses _cygwin_dll_entry@12 from greet.dll and
not from cygwin1.dll. This doesn't work, but I don't know why.

Ralf

>
> Rob
>
>
>
>


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]