How can you change the DLL name in the .idata section header of a DLL?

[Reini Urban]

Charles Wilson schrieb:
> Reini Urban wrote:
>> Just a libtool fake.
>> The deal is that that is a problem for libtoolized packages, when they 
>> don't pick up cygssl*, instead they link statically to libssl.a.
>> It needs some hackery to persuade them to pick up the dynamic version 
>> there.
>>
>> for f in /usr/bin/*.dll; do \
>>     cygcheck $f | egrep "cygssl(-0.9.7)?.dll" && echo $f; done
>> => postgresql, svn, openldap, neon, curl
> 
> There is a reason, actually, for choosing the static version of a 
> security/encryption library: it prevents spoofing the library by 
> replacing the DLL.  But that's neither here nor there.

Spoofing is a good point.
But I might prefer to be able to update dynamic dependencies without 
breakage. openssl usually gets updated with an security issue.
e.g curl or postgresql cannot deal with an openssl update which deletes 
cygssl-0.9.7.dll and replaces that with cygssl-0.9.8.dll.
If we had just a cygssl.dll we can simply upgrade that and nothing breaks.

Anyway, see cygperl.dll:
DLL api's should stay binary compatible IMHO, unless it's really an 
issue (such as int32 => int64 on cygwin's switch from 1.3 => 1.5).
You normally can trust MS DLL backwards compatibility. Newer features 
are just added, or new versioned DLL's appear - newlib2.dll - but old 
DLL's must stay. ("contract")
With our libtool generated DLL names I'm not that happy.

> And Geritt is correct about the linker behavior: it automatically 
> chooses .dll.a (the import lib) when given -lfoo.  The only way to get 
> libfoo.a is to use the -static flag when linking (or ld -Bstatic), or to 
> explicitly list "libfoo.a" as a dependency instead of "-lfoo".
> 
> If your package is doing the latter, I don't think it's a libtool 
> behavior.  It sounds more like a configure.ac/Makefile.am problem.

Yes, indeed.
People forget about -no-undefined in their Makefile.am,
and then on any conflict libtool generates only the static version.
Which was e.g. the case with having -lgdi32 in the dependencies, for 
which no syms could be found.

------------------------------

BTW, a binutils question:
"How can you change the DLL name in the .idata section header of a DLL?"

The linker does create the section with all the magic checksums, so it 
should be doable. But objcopy has no such switch. Does it?
There's a lot of reloc support, and you could change symbol names, but 
not the DLL name, which is as I guess just a special string in the 
.idata (or .lib?) section headers. (see bfd/doc/bfdint.texi)
bfd/coffcode.h has a coff_set_section_contents() function with a
location argument, the name of the shared lib.

objcopy iterates over all sections and calls it via 
bfd_set_section_contents(), but I don't see any matching argument to be 
able to fix the DLL name. Just an oversight, or on purpose?
If it's an oversight I would be happy to provide a patch.

Rationale:
DLL's cannot by symlinked on cygwin, unlike on other platforms.
DLL names are usually quite version specific, which makes perfect sense 
on those other platforms. DLL names are built in the executable PE 
header, so on any DLL rename or upgrade, breakage will occur. On MS 
Win32 old DLL's just stay, so no breakage will occur.
Not so with the cygwin setup.exe.

Solution:
Use as much generic dll names as possible (such as cygperl58.dll, 
cygssl-1.dll, ...).
Provide an objdump option to rename a certain DLL path to fix breakage 
for older libs, until they get rebuilt.

One could also hardcode the DLL path to some /usr/lib; /usr/libexec, 
/usr/<package>/lib, so that we can rid of /usr/bin cyg*.dll pollution. 
But this will only work if the cygwin mount will not change. The windows 
process loader needs the windows path. So "/usr/lib/cygperl.so" might be 
"c:/cygwin/lib/cygperl.so". No major problem if objcopy will support 
that. Something like rebaseall.

Another idea is to make those .idata sections weak and provide a hook to 
go over cygpath resolution via libltdl. If that will work.
Weak is rather new I suppose, and I haven't looked at the implementation 
of lazy linking with ld.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/