Re: %files directive with relocation in %install

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On Jul 4, 2006, at 8:00 PM, Bob Proulx wrote:


While I have nothing but sympathy for your packaging on hp-ux ...

Michael Jennings wrote:
Bob Proulx wrote:
That's nonsense.  "rpath" is simply an additional library search path
which is encoded into the library itself.  Nothing is required to be
in an rpath directory; in fact, it needn't even exist.

Unfortunately rpash is not an additional library path (implying that
it is only searched if not found in the standard places) but rather a
preferred priority location that is searched first.  I will avoid
enumerating the ways this has broken me in the past.


So the problem is ordering on search path, not otherwise.

Like most any other feature, it's not the feature that's bad, but
rather the abuses of the feature.

It is hard not to agree with that statement.  A feature so powerful it
can only be used for ultimate good or ultimate evil.  However I have
never seen it used for good yet.


There are many shades of grey between Good and Evil.

Certainly not rpath's fault.

In fact you can only really test it by installing it!  Better to
avoid it and simply install your libraries a) either in standard
places b) into places configured by ld.so.conf or c) found with
LD_LIBRARY_PATH.

The only difference between rpath and LD_LIBRARY_PATH is that the
former is in the library while the latter is in the environment. They
do the same thing.

They have different search priorities.  If rpath were last I would
have less objections.

The problem is that people tend to use rpath to install libraries in
non-standard locations.  Of course if they were installing in standard
locations then rpath would not be needed.  The installed location is
preferred by rpath.  Therefore the only way to test is to install it.
Or I suppose make sure it is not installed at all.


So blame the mechanism for the idiots.

The entity that causes library relocation problems is not rpath, but
rather libtool .la files.  These files hard-code the locations of
other .la files for other libraries such that, if the .so.* library is
installed but the .la file isn't, linking fails.  *That* is the real
problem, not rpath.

I agree those are also bad.  But trying to classify them by rank
asking how bad each is then I don't know.  They are both bad and I
would like to see both avoided.


So don't put hard coded absolute paths in *.la files.

Both rpath and *.la have their uses.

Besides, isn't that just a feature and as such is not bad by itself as
you pointed out earlier?  Isn't it rather the abuse of that feature
that is bad?  :-)  Sorry, I could not resist.


All depends on how rpath (and *.la) are used.

73 de Jeff

_______________________________________________
Rpm-list mailing list
Rpm-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/rpm-list

[Index of Archives]     [RPM Ecosystem]     [Linux Kernel]     [Red Hat Install]     [PAM]     [Red Hat Watch]     [Red Hat Development]     [Red Hat]     [Gimp]     [Yosemite News]     [IETF Discussion]

  Powered by Linux