ld --auto-import for cygwin and libtool

[Charles Wilson]

Christopher Faylor wrote:


> It's possible that I might be convinced to include Paul's patches in the
> next binutils release if they are not incorporated into the official
> release.  However, I would rather use the official CVS release, if
> possible.
> 


Yes.  And to that end, I'm building and testing stuff.  Specifically, 
binutils with Paul's patch.  autoconf(latest).  automake(latest). 
Robert Collin's libtool(which relies on ld-with-Paul's patch).  etc. 
Rebuild one of "my" packaged dll's using Paul's ld (readline or 
something) and make sure old exe's that depend on it still work when I 
drop in the new dll.  And vice versa: check that exe's compiled with 
Paul's ld, against the new dll, still work if I revert to the old dll. 
etc. etc.

In other words, in addition to the major testing that Robert gave this, 
I'm also now looking at it.  However, I understand that one of the 
sticking points has been the relocation of cygwin1.dll from parent to 
child across fork().  See thread "dll base address" in the 
cygwin-developers archive:
   http://www.cygwin.com/ml/cygwin-developers/2001-06/msg00037.html

Basically, the thread ended with "Well, *perhaps* we might want to think 
about marking cygwin1.dll as non-relocatable -- if it's even possible to 
do so since ld doesn't have a switch like MSVC/link's /FIXED -- and 
*then* we'd *think* about pushing Paul's auto-imports patch into 
binutils.  Furthermore, in a related discussion on the libtool list, 
Chris said

"ld --auto-imports"
http://mail.gnu.org/pipermail/libtool/2001-June/005054.html

"Btw, whether it is a bug in Cygwin or not, I'm obviously not going to
release a binary version of binutils for Cygwin which incorporates
behavior that breaks the use of Cygwin.  In case anyone was wondering.."


Okay, well I've done a little research with MSVC-link /FIXED, and 
cygwin-objdump.  And I've discovered something:

strip -R .reloc my.dll

has the following effect:

It strips the relocation info and the debugging info.  So, the following 
two dll's are equivalent(*):

link /FIXED /DLL <other args> my-fixed.dll

link /DLL <other args> my-reloc-stripped.dll
(cygwin's) strip -R .reloc my-reloc-stripped.dll

(*) with the minor difference that 'strip -R .reloc' ALSO removes the 
debugging symbols.  So, the post-stripped "my-reloc-stripped.dll" is 
just like "my-fixed.dll" except that my-fixed.dll has the debugging 
info.  (a normal "strip" will remove that).

Note that
link /DLL <other args> my-reloc.dll
strip my-reloc.dll
ONLY removes the debugging info; in this case my-reloc.dll is still 
relocatable.

I'm trying to figure out how to get "strip -R .reloc" to remove JUST the 
reloc section and not the debugging symbols; currently, I can't create a 
non-relocatable -- but still debuggable -- dll.

I'm currently running with a cygwin1.dll that has been so stripped.  It 
works.  Now, the problem with this approach is that it's possible for 
cygwin to just "NOT WORK" on a particular system -- if another 
non-relocatable dll already occupies cygwin1.dll's desired address.  I 
dunno how common that problem-scenario might be.

OTOH, if the non-reloc cygwin1.dll loads once -- then all children will 
continue to work properly, and this solves (sortof) the 
fork()/parent/child problem.

So I now have several questions:

Q: Does this sufficiently answer the "Can we mark cygwin1.dll 
nonrelocatable" question -- i.e. do we really need to muck around with 
adding special options to ld.exe (binutils/ld/pe-dll.c) for creating 
nonreloc dll's, or can we just add a strip -R command in the cygwin 
Makefiles?

   subQ: of course, it'd be nice to strip the .reloc but leave debugging 
symbols.  But that (may) require hacking strip.exe 
(binutils/binutils/objcopy.c), but definitely not ld.exe.

   subQ: do we want to pursue this "solution" for the 
fork()/parent/child problem?

Q: If so, then (pending further compatibility tests, of course.  I'm 
working on it) can we start experimenting with including Paul's patch in 
binutils?

   subQ: I'm still not sure why the auto-import stuff is gatewayed by 
the fork()/parent/child problem.  They seem orthogonal to me, but 
whatever...

--Chuck