> > I would like to submit a patch to disable rpath
> > by default, and add a '--enable-rpath[=DIR]' configure
> > options. Objections?
> we do have to use rpath so that we don't need to tweak
> the LD_LIBRARY_PATH or /etc/ld.conf on any user configuration
>
> since your request is specific (and using rpath seemed to be
> agreed on latest Wine bottling discussion), I'd suggest doing
> it the other way around:
> - keep rpath as default
> - add a configure.in option (--disable-rpath) to remove that
> feature in case it's not wished
>
You know, I didn't realize how well Alexandre had set me up.
I had sent a --with[out]-rpath=DIR patch to Alexandre, which behaved
exactly as you suggested, and asked for his feedback.
He responded:
> So if I get this right, what you do is that you don't set -rpath at
> all? I'm beginning to think this should actually be the standard
> behavior; setting rpath is broken because it takes precedence over
> LD_LIBRARY_PATH. How about submitting a patch that removes rpath
> completely, and start a nice flame^H^H^H^H^Hdiscussion on wine-devel?
I'm sorry for picking at this scab, but after some thought, I
think he's right.
If the -rpath did *not* take precedent over LD_LIBRARY_PATH,
then I would not object to it, but that precedence is, IMHO, a nasty
hidden surprise.
For example, in the RPM I've nearly finished building,
I've allowed for the installation to be relocated.
So, you can do rpm -i wine-0.2000-1108 (which goes to /opt/wine).
Later, you can do a rpm -i --prefix=/opt/newwine wine-0.2000-1216,
and install to /opt/newwine.
However, running anything out of /opt/newwine, regardless of
LD_LIBRARY_PATH,
gets you routed directly back to /opt/wine. That's the sort of subtle
thing that would cost me hours and much lost hair before I clued in to
it.
Jer
