Mail Archives: cygwin/2004/09/30/05:56:59
[ I switched from cygwin-apps, where it is not appropriate ]
Charles Wilson schrieb:
> Reini Urban wrote:
>
>> 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.
>
>
> That's the way most other DLLs on cygwin are named. But cygssl is
> different -- as a security/encryption DLL, considerations other that
> "ease of slipstream replacement" are more important. Usually there is a
> reason when a maintainer chooses to go against the common practice:
> openssl is one of those.
>
>> 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.
>
>
> Perl's build system is a nightmare. We're lucky we have a shared
> version at all. But if you want to assist Geritt in fixing some of the
> warts in the perl build system, I'm sure he'd welcome patches (and, as I
> indicate below, concentrating on the ACTUAL problems rather than trying
> to wholesale rework libtool/binutils/gcc/etc is probably a quicker path
> to solving your issues).
>
> That name (cygssl-0.9.7.dll) is not libtool's fault. Libtool uses two
> different mechanisms for setting the name of a DLL:
> -version-info c:r:a
> and
> -release x.y.z
> There are explicit rules governing how c, r, and a are to be updated,
> and how the dll name is derived from c,r,a in order to insure that (a)
> the library name changes rarely, and only when necessary to indicate
> binary incompatibility, and (b) all dlls with the same name are
> backwards compatible (e.g. old exe's linked against the old DLL will
> still work with the new DLL). The libtool maintainers STRONGLY suggest
> using the -version-info paradigm. On cygwin, this results in library
> names like libintl-3.dll (NOT libintl-0.12.1.dll) Most cygwin packages
> which provide DLLs obey these rules and follow this "suggestion".
>
> But the libtool folks do provide the -release mechanism, which is often
> used to name the DLL using the major.minor.micro revision numbering
> system. There are sometimes good reasons to do this, but usually it's
> because the package maintainer doesn't understand library versioning, or
> libtool. cygssl behave this way (even though it doesn't use libtool IIRC).
>
> If libtool names were used "correctly" by the packages, then you would
> be "happy" -- and further, on cygwin we take GREAT PAINS to ensure that
> compatibility DLLs are kept around virtually forever whenever DLL names
> do change. So what, exactly, is your beef? Just perl and ssl -- and
> THAT justifies reworking libtool and binutils, and rewriting the
> underlying conventions of DLL names and cygwin's runtime loader?
Many thanks for this explanation. I was wrong.
>> 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.
>
>
> It seems that the problem is NOT, then, libtool or the
> existence/non-existence of a .la file. The problem is the "conflict"
> (e.g. build errors in the package in question). Focus your efforts on
> fixing the problem, not band-aiding a "solution".
True. 99% of all conflicts are just incorrect object and library order.
Seldom they miss a .o, lib or add a wrong dependency.
>> ------------------------------
>>
>> BTW, a binutils question:
>> "How can you change the DLL name in the .idata section header of a DLL?"
>
> Don't do that.
>
>> 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.
>
>
> Faulty. DLLs don't often change names, and when they do, the old
> versions stay around. If not, then THAT is the problem.
Persuaded.
> For instance, how many versions of libintl*.dll do you have on your
> system? libncurses*.dll? cygtiff*.dll? cygjpeg*.dll? cyggdbm*.dll?
> cygdb*.dll?
>
> Are you noticing a pattern yet?
You caught me. Indeed.
> It appears that your biggest beef is with the cygssl (and perl) DLL
> naming scheme: it uses -release versioning (even tho it actually doesn't
> use libtool to do it, IIRC). (perl does something even wierder; I'm not
> going there).
>
> This presents a difficulty for packages which depend on cygssl*dll.
> However, this IS one of those times when there is a good reason to
> change the DLL name on every security fix (e.g. micro release version).
> It means you can't silently slip an SSL bugfix into an older version
> of imapd, but you also can't silently slip in NEW SLL security holes
> possibly introduced by the new library.
>
> Each dependent app can make its own determination that "Yes, the bugfix
> in version+1 outweighs the risk of new bugs, so I will now recompile
> against the latest version".
>
> Downside: on our platform, at present, it appears that "older" versions
> of cygssl*.dll are not retained, because the "openssl" package is not
> "split" into independent "library" and "other" packages: e.g.
> libssl0_9_7 package contains /bin/cygssl-0.9.7.dll
> libssl0_9_8 package contains /bin/cygssl-0.9.8.dll
> while
> openssl package contains every thing else.
> That is a maintainer issue, and I'm sure there is a good reason (perhaps
> the openssl package itself is not amenable to this splitup. For
> instance, suppose that the "everything else" is version-specific, yet
> lives in /usr/share/openssl/. You'd need multiple versions of
> "everything else" but they all want to own the same directory. Problems.)
>
>> Solution:
>> Use as much generic dll names as possible (such as cygperl58.dll,
>> cygssl-1.dll, ...).
>
> But that IS what we do, *whenever* possible. When we (cygwin pkg
> maintainers) don't, there is usually a good reason. One which, quite
> frankly, you obviously haven't done enough research to identify ==
> because you're focusing on libtool and binutils issues, when it appears
> the difficulties are much more localized to the specifics of a few
> packages like openssl and perl.
>
>> Provide an objdump option to rename a certain DLL path to fix breakage
>> for older libs, until they get rebuilt.
>
> God no. If anyone ever does such a thing to any of the DLLs supplied by
> my packages, and then comes complaining to the cygwin list because "tiff
> doesn't work anymore" not only will I not support their bastardization,
> but I will drop the tiff package from the distro like a bad habit.
:) If nobody wants it, I will not write such a hack. Rebuilding the DLL
is easier.
> I do NOT have enough time to support people who take a hexeditor to the
> internals of the packages I supply. Use them as is, or don't use them
> at all.
Thanksfully the section headers are protected by two checksums (and even
more magic), so nobody can hexedit the DLL name :)
I knew that there must be an explanation, but I couldn't find it.
So it would only fix the perl problem, but for perl alone it will be
MUCH easier to provide a package update. Agreed.
And no package so far uses a embedded shared perl interpreter, to my
knowledge. Just postgresql starting with v8.0, for v7.x it is broke).
That are my primary concerns, because I just want to take over from Jason.
>> 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.
>
> The windows loader will only load .dlls (and .ax but that's a special
> case for the COM+ architecture AFAIK). And .dlls follow certain rules.
> It will not load .so's even if the .so contains pei-386 code. You need
> a special loader to do this instead; something like libltdl would have
> to be built into cygwin1.dll -- but it wouldn't be exactly libltdl for,
> I hope, obvious reasons.
You got me wrong. My "/usr/lib/cygperl.so" up there is of course a
binary DLL (Ix86 COFF with PE), with just a funny filename.
In my experience LoadLibrary (dlopen) will load any filename ending with
any extension, as long as it is a true DLL - relocatable Ix86 COFF with
PE and some more restrictions. (PEI is just the win32 version, an old
header prepended, printing the "This program cannot be run in DOS mode"
warning. I believe.)
As long as you provide the basename+extension. path not necessary.
basename is not enough (Default: ".DLL"). Hell, Windows even thinks that
the extension of "perl5.8.1.dll" is "8.1.dll", and not "dll". But this
may vary, depending on the library function used internally.
>> 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.
>
> Hell, I don't even know if weak WORKS on cygwin; it was developed over
> in the mingw arena; as far as I know they didn't even test it on our
> side of the fence. And you want to replace the shared library mechanism
> with it? Walk before you run...
I believe it was developed by the WINE folks, because MSVC suddenly
supported lazy loading (requested by some folks, like Autodesk) and the
WINE folks had to load these beasts. gcc-core (or just binutils?) picked
it up lately, but I don't think the decided on the ld switch naming yet.
I don't follow these lists, just the ChangeLog.
ld --help |grep delay
ld --help |grep lazy
It is just an early idea, but I don't think a bad one.
And there's no hurry: I don't want to replace it. Just talk about it.
If would make sense.
> All of these ideas (like using a cygwin runtime loader instead of
> relying on DLLs and the Windows Runtime Loader) have been brought up
> before. But nobody has demonstrated any working code, nor demonstrated
> 1/10th the amount of thought necessary to forestall the problems
> inherent in those plans. Show me the code.
Where? (just a rough substring would be enough to google it)
I couldn't find it anywhere. Most of the things I found at WINE, and
know from my former MSVC + AutoCAD + FFI days, where Autodesk developed
its own DLL loading + extension scheme, just to support C++ class
extensions and overloading by external DLL's. Which I hacked and
extended for lisp.
> Look, I know this message (and my last) have been snippy. I'm sorry for
> that, but about every three months somebody comes along with a great
> idea to "fix" a problem with DLLs on cygwin. (Usually -- although not
> in your case -- the problem is actually between the keyboard and the
> chair) They almost never demonstrate a thorough understanding of the
> issues surrounding dynamic libraries, naming schemes, the Windows
> Loader. Further, they often approach the current paradigms with faulty
> assumptions (e.g. cygwin DLL names change often; they don't; DLLs are
> removed by setup willy-nilly; they aren't [current problems with
> cygwin1.dll+setup notwithstanding]) nor do they understand the reasons
> things are done as they are presently.
>
> So please, before you continue on this path, go back to the earlist
> cygwin-apps archives, and read...then, read it again. We HAVE thought
> about these issues.
--
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
- Raw text -