This is the mail archive of the cygwin-apps@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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 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/



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]