Hi! Speaking for myself as a Debian maintainer (not a libtool maintainer):
Alexandre is angry because we have deliberately chosen not to fully implement Red Hat's ugly (and effective) ld.so hack, but yet we also claim that we're ``just following what everybody else is doing,'' and that none of the -rpath problem rests on our shoulders. This position is untenable. Either we *choose* to follow everybody else, or else we accept responsibility for our actions (which means implementing our own fixes, not demanding others to fix problems for us). ``But libtool already has specialized code for so many other platforms, why can't it we force it to change, too?'' Because libtool already has enough crap to deal with, and it doesn't need any more. I made libtool deal with @%^#ing Solaris problems (older `echo' programs dumped core on lines longer than 1k: their ``fixed version'' segfaults on lines longer than 2k). I'll tell you, if it was *GNU* echo that was broken, I would have complained much louder and longer before even *thinking* about changing libtool to work around the problem. The implications of my Solaris changes repurcussed for many releases. That's the main reason why libtool has a bad reputation: my Solaris changes broke libtool on another platform, then fixing that platform broke on another, etc. Do not underestimate libtool's complexity! It's bloody hard to write a shell script that does something non-trivial and works on every known unix platform. (Which begs the question: why isn't it written in C? Because it would be even *harder* to maintain. If you disagree, prove it with code.) Alexandre is much nicer than I am. He's provided a patch script that will automatically disable -rpath in libtool, and he's also figuring out flags to allow the package maintainer to disable -rpath whenever they want. But his messages carry the same attitude that I would have in his position: ``what the hell?!! Debian's ld.so can't cope with -rpath?!!'' Just remember that he's telling us about it for the benefit and stability of Debian as a whole. If it was a proprietary vendor's problem, he'd just work around it without telling them, because he doesn't care if the vendor's Unix is buggy or not, and they probably wouldn't listen to him anyway. In short, we have only three choices, regardless of what happens in libtool: 1) Implement Red Hat's ugly patch in our libc5 ld.so, and thereby be bugwards compatible with everybody else's Linux. 2) Find some other way to make -rpath on Debian work for the common cases (programs built by libtool included in this category). 3) Remain content with the fact that using -rpath will always give people problems on Debian systems, in a way that it it doesn't on any other major Linux distribution (or any other major Unix, for that matter). Make sure no Debian packages use -rpath, patching packages that do, and tell people that foreign binaries using -rpath sometimes won't work on our system. The current Debian policy is #3. IMNSHO, that's exactly the wrong approach. It forces Debian maintainers to weed out -rpaths, which is a change that many upstream maintainers won't accept (since it's not needed on any other system), so we'll have to keep reapplying it to new upstream versions. Worse yet, it means that we won't ever be 100% binary compatible with any other dual libc5/libc6 system (such as Red Hat). That sounds like a Debian policy decision to me, *not* a clear-cut technical decision. Unless somebody can give me a good reason why we shouldn't, I think we should put it to a formal vote. My proposal would be: should Debian allow packages to use `-rpath' in a way that works on other Linux systems? If so, we need to do something to fix the common cases (whether EWT's ugly patch, or not), and we can relax about packages that use `-rpath'. Comments are appreciated, -- Gordon Matzigkeit <[EMAIL PROTECTED]> //\ I'm a FIG (http://www.fig.org/) Lovers of freedom, unite! \// I use GNU (http://www.gnu.org/) [Unfortunately, www.fig.org is broken. Please stay tuned for details.]