This is the mail archive of the
mailing list for the Cygwin project.
How can you change the DLL name in the .idata section header of aDLL?
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
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.
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.
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.
Use as much generic dll names as possible (such as cygperl58.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.