[debian-devel:10434] Re: rpath is evil?

[Taketoshi Sano <xlj06203@xxxxxxxxxxx>]

佐野＠浜松です。

 comp.os.linux.development の話題から。面白かったので、転送します。

# 何故 bo の X11 関連プログラムが hamm で動かなくなったのか、
# その理由はやはり rpath だったと見て良さそうです。

In article <7s77ku$aqo$1@xxxxxxxxxxxxxxxxxx>
 peter@xxxxxxxxxxxxxxxxxx (Peter Samuelson) さん writes:

> [Todd Knarr <tknarr@xxxxxxxxxxxx>]
> > The system the program is installed on isn't the one you developed
> > on.  You make a set of assumptions about where libraries reside based
> > on what you did.  Programmer B makes a different set of assumptions.
> > Programmer C makes yet another set of assumptions.  When dealing with
> > any significant number of packages, you can pretty much guarantee
> > that there is no configuration which satisfies the assumptions of all
> > of the programs at the same time.
> 
> And this is more or less why I originally said that "rpath is broken"
> in most instances.  This was a flame war some time ago on the
> debian-devel list between Debian luminaries and the maintainer of
> libtool.  libtool makes generous use of rpaths, and this was causing
> problems in Debian.  Scenario:
> 
>   * One version of Debian, call it "bo", ships with libc5.  This sits
>     in /lib, with other libs in /usr/lib, /usr/X11R6/lib and so forth.
>     Packages compiled against libc5 work fine on "bo".
>   * Next version (call it "hamm") comes out based on libc6.  Libc6 and
>     all its syncophants also sit in /lib, /usr/lib and /usr/X11R6/lib.
>     libc5 and *its* syncophants (and we all know that libXpm compiled
>     with libc5 isn't compatible with libc6, etc) sit in
>     /usr/libc5-compat/lib and thereabouts.  Programs from the "bo" era
>     still work fine.
>   * However, "bo" X11 programs compiled with libtool all inexplicably
>     break.  Turns out that they are all using rpaths and they all think
>     they need "libX11.so.6" to be in /usr/X11R6/lib.  If they didn't
>     use rpaths then the linker would have sorted everything out and
>     given them libraries in /usr/libc5-compat/X11R6/lib instead.
>   * Flame war with libtool maintainer.  He maintains [n.p.i.], quite
>     reasonably, that when a library is incompatible with a previous
>     version of itself it needs a new soname.  But Debian is right, too:
>     you can't just twiddle the sonames of every library that you ever
>     have to recompile against the new libc.  (libX11.so.6.libc6 ?!?)
>     Besides, it doesn't end there.  What if you compile multiple
>     versions of libgnome that depend on libgtk 1.0 and 1.2?  Again,
>     you'd need two distinct sonames for libgnome which, after all, may
>     well be compiled from the same source code.  Do a cross product
>     with libc and you could get four sonames.  Where does it end?  You
>     can't keep creating directories forever.
>   * Ergo, rpath is evil.  It shouldn't be used as default policy, since
>     the Linux linker (unlike the Solaris one) is smart enough to
>     resolve a lot of those kinds of dependencies on its own.  It should
>     be used only where absolutely necessary.
> 
> There was, I believe, a happy ending, after much carnage.  Debian now
> maintains a slight fork of libtool which doesn't use rpath, and Debian
> packages which use libtool are pointed at the in-house version at
> compile time.
> 
> > > I would use it especially on a production system, because otherwise
> > > you never know, what will happen, when you install a new library
> > > file. Otherwise you probably will get stoned by the other users of
> > > the system!
> 
> You upgrade libraries on production systems?  Without testing all the
> software users will stone you for?
> 
> > > Lots of system operators and users of Solaris systems have had
> > > enough experience with shared libs to say: An application, that
> > > needs LD_LIBRARY_PATH (and so /etc/ld.so.conf) is broken!
> 
> Ah, the difference.  Solaris doesn't use an /etc/ld.so.conf.  Every
> program that doesn't have an rpath gets the system default which IIRC
> can't be changed.  So your choice is either an rpath or one script per
> executable that does little but set LD_LIBRARY_PATH.  Not to mention
> that LD_LIBRARY_PATH (and the script for that matter) won't work for
> setuid binaries.
> 
> > -- 
> > If I employed software developers and they gave me something like
> > this, I'd shoot them.
> >                                 -- Abby Franquemont
> 
> I like it.  Quite apropos.
> 
> -- 
> Peter Samuelson
> <sampo.creighton.edu!psamuels>

# 誰か気が乗ったら翻訳してみてください。

-- 
     ＃わたしのおうちは浜松市、「夜のお菓子」で有名さ。
    <xlj06203@xxxxxxxxxxx> : Taketoshi Sano (佐野　武俊)