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] |
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.
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?"
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.
-- Chuck
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |