Debian's -rpath policy [was: What hack in ld.so?]
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
``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
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
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
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@example.com> //\ 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.]