[Top][All Lists]

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

Re: ld --auto-imports

From: Robert Collins
Subject: Re: ld --auto-imports
Date: Mon, 11 Jun 2001 10:10:00 +1000

----- Original Message -----
From: "Paul Sokolovsky" <address@hidden>
To: "Robert Collins" <address@hidden>
Cc: <address@hidden>; <address@hidden>
Sent: Monday, June 11, 2001 3:35 AM
Subject: Re: ld --auto-imports

> Hello Robert,
> âîñêðåñåíüå, 10 èþíÿ 2001 ã., you wrote to me:
> RC> Hi Paul,
> RC>     You may not recognise my name - I hack on the cygwin1.dll
> 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.

I'm not subscribed to binutils either, so I too would appreciate that
courtesy from other repliers.

> RC> Your ld patch looks very nice, and I have a modified libtool-HEAD
> 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
> . 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).

I wanted to push it's limits, because introducing it into libtool for
example requires that it has at least the same level of functionality
that libtool does. In fact it was Ralf's reporting his success on the
cygwin-xfree list that got me motivated :].

<SNIP background>
> RC> for .dll's should be 0x10000000. Is there any reason your modified
> RC> couldn't set that as the default base address for .dlls? That
> RC> remove the need to add --base-address=0x10000000 to the link line
> 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.

Is it? Ahh. Sounds like it's time for me to roll-my-own.

> 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.)

I tried that. ld still created an image base of 0x610c0000.

> 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 ;-)

I agree with you, please see me answer to 2 for a potential problem :].

> RC> Now for the more serious question. Does your patch in theory
> 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
> RC> will be the same without libtool) that segfaults _every time_.
> 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
> RC> trivial testcase, and/or prepare a non-libtool testcase that shows
> RC> same symptoms - if that would help.
>     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).

It's 200 kb, because I've included the compiled version, in case you get
different results when building and or linking. As such, I've put it so that anyone involved
in this discussion can grab it for review. It's derived from the goat
book's hello test case.

The testcase is bare bones: no libtool, autoconf, automake. If you can
identify the issue, and a workaround, I'm happy to put in the elbow
grease to get libtool doing that.


> RC> Rob
> --
> Paul Sokolovsky, IT Specialist

reply via email to

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