Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Date: Mon, 17 Feb 2003 10:28:27 +0000 (GMT Standard Time) From: Max Bowsher To: Charles Wilson cc: cygwin Subject: Re: [avail for test] libtool-devel-20030121-1 In-Reply-To: <3E507DD6.1030203@ece.gatech.edu> Message-ID: X-X-Sender: mob22 AT imap DOT hermes DOT cam DOT ac DOT uk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 17 Feb 2003, Charles Wilson wrote: > Max Bowsher wrote: > > > Besides, this means altering the platform to suit libtool. Talk about the > > tail wagging the dog! > > see below > > >>The only alternatives for this particular problem seem to be: > >> > >>1) punt. > > > > Well, it's not like we've got many complaints about this. > > > >>2) delay. --enable-runtime-pseudo-relocs will be the default **on > >>cygwin** someday (never on mingw). Wait until then, or push it now. > >>In any case, once it is the default, then we can simply dllize libuuid, > >>and then -luuid will grab the import library, and libtool will be > >>happy. But this can never be the solution for mingw. > > > > And, as I say above, is ridiculous. Libtool is supposed to assist > > portability - no force platforms to redesign themselves. > > No, not really. You still have to conform to certain basic rules -- > libtool is not a magic black box ("dump all .c, .f, .C, and random .o or > .a files here, turn crank, and I'll do the right thing"). > > Fringe platforms -- like cygwin -- have always had to do strange things. > In the 1.4.x libtools, you had to have special declarations in your > header files. You had to entirely avoid backlinking. You had to include > a special flag (LIBTOOL_DLL_WIN32. I think) in configure.in. And > "normal" platforms still have to follow certain rules. > > We've done a LOT of work over the past two years to hide these things > from you. There have been countless changes in the cygwin kernel, > libtool, autoconf, automake, binutils, and gcc to enable the present > functionality -- and now, building dlls with the -devel autotools > framework is so much like unix, that you think it should be *exactly* > like unix. Even when accessing *windows-specific libraries* like > w32api/libuuid.a! Hmm. It seems us relative newcomers to Cygwin are fortunate to have never experienced the bad old days! > There's one big non-unixism I'd like to get rid of, but the solution is > cygwin-specific. It won't be supported on mingw (or -mno-cygwin). And > that non-unixism is the "difficulties" with data imports from a DLL, > where the datatype has multiword storage. --pseudo-relocs solves that > problem, but (in reality) it's only a viable solution for libtool > purposes once it becomes the default setting in ld.exe. But, since > pseudo-reloc exe's require runtime support...it is unwise to enable it > as the default on mingw, since mingw DLLs are supposed to be usable by > standard windows tools (e.g. MSVC). DLLs which require pseudo-reloc > support in the linker and runtime are NOT portable to standard windows > tools. Since on a cygwin system, we *know* we will always have > cygwin1.dll -- and because we don't support any other compiler than > gcc/binutils -- we're safe in making our DLLs pseudo-reloc dependant, on > the rare occasions where that becomes necessary. Thus, this is a > cygwin-only, not mingw, solution. > > Anyway, I was talking about "rules" you must follow -- in any build > environment (like libtool). One of the old, and still current, rules is > that on windows/cygwin/mingw, you must use -no-undefined [and it better > be true!] -- because you can't make a DLL with undefined symbols. Now, > one of the NEW rules is "ensure that all dependencies are dynamic." If > the are not, fine -- libtool won't *fail*. It will simply build a > static lib. But because you haven't followed the rules for shared libs, > libtool won't build a shared lib. Yesss.. but, when building glib, if one of its components gets staticized, the next one fails to link. > the choice is simple: (1) figure out how to *modify the cygwin platform* > to ensure that ALL system libs are available in shared form, or (2) > modify libtool and weaken the existing policy. > > that's it. (1) is not really an option, since w32api is an alternative implementation of something essentially defined by Microsoft. > In the past, we've done either -- I modified libtool so that it wouldn't > complain about compiler runtime libs [dllized compiler libs, while a > laudable goal, are WAY too hard without MASSIVE changes in the gcc > sourcecode. Fortunately, Zack and Nathanael are gluttons for > punishment. Their goal is converting gcc/binutils to use modern > autotools -- and that's 95% -- 100% of the work, given the -devel > autotools on cygwin] At other times, we dllized certain existing add-on > libraries so that a new port of a different library could be added to > the cygwin system in dllized form, straight from its very beginning. > > I hope that once Zack and Nathanael's work in the gcc and binutils tree, > updating them to modern autotools, is done, that our gcc builds will > suddenly include shared compiler runtimes...but I'm not holding my > breath on that score. And *hopefully* that change won't require any > work on cgf's part: it'll just "happen". > > Most of cygwin's runtime support libs are shared. [e.g. ALL of mine, > and I provide a lot of 'em; other maintainers have been just as > proactive]. Most of the w32api libs -- since they are derived from MS > DLL's in the first place -- are shared. There are only a few -- six -- > exceptions. > > And you are arguing *against* improving our platform by making all libs > available as shared, simply because it's driven by a libtool > requirement? sheesh. Not exactly. w32api currently more-or-less follow the file layout of the Platform SDK. That's what I'm arguing against changing. > >>3) kludge. Put a special-case exception for -luuid and libuuid.a -- > >>and the other four !@#$!@# static libs in w32api -- into the libtool code. > > > > Messy. > > Yes, quite. But it's still better than... > > >>4) revoke the libtool policy; DLLs with static dependencies are just > >>dandy. > > > > I like it. > > You may like it, but IMNSHO, you're wrong. Think about libpng, for > instance -- which depends on libz. > > Now, suppose I ship a libpng.dll which was linked with a static libz.a, > and further suppose that there's some global static symbol in libz -- > call it, "encryption_key". Now, libpng.dll doesn't RE-EXPORT that > symbol; why should it? "encryption_key" belongs to libz. But if > libpng.dll were linked dynamically to libz.dll -- and my application > were linked dynamically to both libz.dll and libpng.dll -- then my app > would ALSO have access to the *public symbol* exported by libz.dll, > which libpng.dll uses. > > However, I then write a problem, chuck.exe, which links against > libpng.dll. Now, if I don't use any libz routines *myself*, I don't > need to link chuck.exe against libz, because libpng.dll has had its > dependencies satisfied *statically*. (In real life, cygpng.dll is > linked dynamically against cygz.dll, so chuck.exe DOES need to add '-lz' > even if chuck.exe doesn't access zlib functions itself. But that's real > life. Back to the fairytale:) However, suppose further that chuck.exe > DOES use zlib directly. But now, zlib has changed. There's a new > version available...in which the "encryption_key" is double, instead of int. > > Now what? (a) which version of encryption_key gets used by chuck.exe? > double, or int? (b) since it's a "global static' you would think that > if chuck.exe changed its value, chuck.exe could reasonable expect that > change to affect how the libpng routines work. but it won't -- because > cygpng has its own private copy. > > For instance: chuck.exe sets encryption_key to "4.234123" -- but libpng > saves an encrypted file using some other, random key [that I don't know > the value of, and which in this context is a CONSTANT probably equal to > ZERO, because I have no ability, from chuck.exe, to change libpng's > private copy of that variable!!] > > Okay, so maybe we let libpng re-export "encryption_key". Fine -- if > that's the ONLY thing I need from libz, all is well. I link against > only -lpng, I can access the re-exported (private static copy of) > "encryption_key". But what if I also need to compress/uncompress other > zlib streams? Then I need to link against -lz -- and I'll get a symbol > conflict. [I'm glossing over some things here like "static symbols > override dynamic imports" -- but then you'd be right back in the > situation described above.] > > Okay, so libpng's re-exported version of encryption_key is exported > under a different name. Now, there's no symbol conflict. It'll work -- > but look what you've done; you've basically forked the zlib interface. > You might as well snarf all of the zlib code into libpng itself, and > drop any dependency whatsoever on the "real" zlib. This is not progress. > > It's a silly example, of course -- but you could probably find a real > life example if you looked hard enough. And that's why I think the > libtool policy change is a GOOD one. Shared libs, in general, should > not have static dependencies. Aargh! At least I now have a little more insight into *why* this policy exists. > > But it's not going to happen. So: > > How about a flag, like -no-undefined ? > > For example: -i-know-what-i-want-to-link-dont-interfere-please :-) > > --shoot-self-in-foot-with-unpredictable-consequences ? > > I've noticed that most of the time (but not always) when folks complain > about libtool being too smart for its own good, they don't understand > WHY libtool makes the decisions it does. Sometimes, most of the time, > libtool *really does know best*. Or at least, libtool knows better than > the wet-behind-the-ears developer who can't get it to act like she wants > it to. Ok - I concede the point that, most of the time, when libtool does something unwanted, it's because no-one has bothered to teach it about the peculiarities of the platform. > I trust that you will not bring up those numerous occasions where *I* > have complained about libtool being too smart. Thanks. > > >>All four alternatives suck. #4 is the worst; it won't happen. #2 > >>won't help mingw. That leaves #1 and #3 -- and I hate kludges. How > >>important is this? Is "punting" really such a bad idea? > > > > Punting is acceptable, if necessary. What do you think about my flag idea? > > It's just another way around the rules -- and these are rules I happen > to agree with. I'd rather put special-case in there specifically for a > small set of [4!] known libs, because I know those won't be abused. > "Gee it's too hard to build libsilly as a dll, I'll just link my > cygsillier.dll against libsilly.a, and use Max's --shoot-self-in-foot > flag..." Ok. Makes sense. Maybe I'll get round to making patch for this. Max. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/