AW: ld --auto-imports

["Ralf Habacker" <Ralf dot Habacker at saght dot tessag dot com>]

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.


--old-----------------------------------------------------------------------
-----------------

CC=gcc -mno-cygwin

all: greet.dll hello.dll hello.exe

greet.dll: greet.o
	$(CC) --shared $^ -o
$@ -Wl,--out-implib,libdll.a -Wl,--image-base=0x10000000
                                               ^^^^^^^^
hello.dll: hello.o
	$(CC) --shared $^ -o
$@ -Wl,--out-implib,libdll.a -Wl,--image-base=0x10000000 -L. -lgreet
                                               ^^^^^^^^
hello.exe: main.o
	$(CC) -o  $@ $^ -L. -lgreet -lhello

clean:
	rm -f *.o *.dll *.exe *.map *.a

--new-----------------------------------------------------------------------
-----
CC=gcc -g

all: greet.dll hello.dll hello.exe

greet.dll: greet.o
	$(CC) --shared $^ -o
$@ -Wl,--out-implib,libgreet.a -Wl,--image-base=0x10000000

hello.dll: hello.o
	$(CC) --shared $^ -o
$@ -Wl,--out-implib,libhello.a -L. -lcygwin -lgreet -Wl,--image-base=0x10000
000

hello.exe: main.o
	$(CC) -o  $@ $^ -L. -lhello -lgreet

clean:
	rm -f *.o *.dll *.exe *.map *.a


Regards Ralf



>
>
>
>
> --
> Paul Sokolovsky, IT Specialist
> http://www.brainbench.com/transcript.jsp?pid=11135
>

>
>