This is the mail archive of the gcc-help@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: A question about RPATH



> > The libs fir libiconv and GNU gettext are in /usr/local/lib and not 
> > anywhere to be found in the system lib areas : 
> 
> The disadvantages of RPATH are well-documented.  

Really?  Name one please. 

> Perhaps its usage is
> common on Solaris, but we don't much use it on Linux.

That would be a weakness then. A long standing standard is that non-vendor supplied software should be installed into /opt with config in /etc/opt and /var/opt etc etc with the vendor names at the end of the path. Much like the way MySQL or Oracle database is installed. The vendor has no reason to rely upon the OS supplier for libraries however they may choose to. Therefore a vendor of software that has concern for quality and control of the users expected results will generally provide the libs required also and they will be in the directories such as /opt/foo/lib for example. The binaries will therefore have a RPATH set to use the libs from the software vendor and thus isolate the expected software results into a region of control that the software vendor can respond to. 

The usage of the new defacto /usr/local is a new concept and seems to work fine within the Linux world however Red Hat is very far behind on version releases for many things, therefore I build my own dependecies and then ensure that with -Wl,-rpath=/usr/local/lib or similar I can isolate my software from the Red Hat versions. 

> Your problem is best solved by installing dependent libraries where
> ld.so can find them. 

Yes and no. Again I could argue the point from the perspective of control and quality. If I rely upon the software from the OS supplier ( Red Hat, Debian, Oracle ) then I must assume that the OS vendor is on top of things and provides reasonably up to date software that addresses security and feature concerns. This is rarely the case and the trade off between stability and feature rich end user tools is always a tough balance. I therefore choose to build what I want and isolate it from the OS vendor. 

>  ldconfig can do this, but if these libraries
> are available as standard packages that's hugely preferable.

to whom ? 

Dennis 


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]