Re: Advice on rpath

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

 



> ERROR   0001: file '/usr/bin/xapian-tcpsrv' contains a standard
> rpath '/usr/lib64' in [/usr/lib64]

The problem here is that the program doesn't understand 64-bit multilibs. 
Rpaths are supposed to be set only for directories which are NOT standard 
library directories. Unfortunately, the build system used by this program (and 
all the others having the same issue) does not understand that /usr/lib64 is a 
standard library directory (or worse, it might just unconditionally put the 
rpath there). If this is a libtool-based build system, "relibtoolize" with the 
Fedora libtool (i.e. run "libtoolize") to fix this. If this is a simpler build 
system, like QMake, CMake, SCons etc., it's usually a one-line fix in the 
project description.

> Is it acceptable for fe-extras to ignore this error?  AFAICT, this is
> harmless.  What is the motivation to make this an error?

Well, if you want an official answer, you have to ask the ones who set the 
policies. (That would probably be the Fedora Packaging Committee in this case.) 
However, here are some reasons: The rpath is redundant, so it is probably 
inefficient. It also breaks if some future version of Fedora moves the libs 
to /usr/lib (i.e. no more multilib), /usr/lib64-oldabi (e.g. if some big GCC 
ABI change hits), /lib64 (i.e. no more /usr, which might be possible even for 
NFS setups using some unionfs-type solution) or whatever other location.

        Kevin Kofler

-- 
fedora-extras-list mailing list
fedora-extras-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-extras-list

[Index of Archives]     [Fedora General Discussion]     [Fedora Art]     [Fedora Docs]     [Fedora Package Review]     [Fedora Desktop]     [Big List of Linux Books]     [Yosemite Backpacking]     [KDE Users]

  Powered by Linux