Re: gEDA: gschem rpath autoconf test

[Hamish Moffatt <hamish-at-NOSPAMdebian_dot_org>]

On Fri, Jan 28, 2005 at 01:38:18AM +0100, Mario Klebsch wrote:
> Am 26.01.2005 um 22:47 schrieb Hamish Moffatt:
> >I'm not sure that LD_LIBRARY_PATH overrides RPATH. Can you prove it?
> 
> If it would not override, X11 would not build. The X11 build does 
> create executables using RPATH, which are executed during the 
> compilation process and so must use the freshly compiled uninstalled 
> copies of the libs instead of using a possible broken one previously 
> installed.

OK, I'll take you word for it. I know nothing about X11 builds.

> BTW, your example does not count, because you are arguing on the 
> location of the system libraries. I never would use RPATH to hard code 
> the path of system libraries. But there really can be no doubt, that 
> libs like libSDL, libavifile, libgtk, libguile, libxml, libartsc, 
> libkdecore, libqt-mt... (just to name a few) can NOT tbe considered to 
> be system libraries, no meter wetehr some/several/most/lots of 
> distrobutions may include the in system locations.
> 
> As long as gschem intends to be portable among UNIX platforms, it 
> cannot assume, that all libs required are system libs. This assumptions 
> is especially nonsense for packages including their own libraries. 
> These libs cannot be system libs, as they are not suppied by the 
> system.

Two points in reply.

1. On many distributions, they are effectively system libraries. Debian
   installs libgeda.so.22 into /usr/lib.
2. If an admin installs gEDA into /usr/geda(/lib,/bin,etc) they can
   add /usr/geda/lib to /etc/ld.so.conf. There is no need to use RPATH.

> Have you ever tried to let your users use several verions of e.g. X11, 
> KDE, Gnome ´,.. on your system, each user possibly using a different 
> version at the same time? UNIX is a multi user system and there are 
> systems out there, where the users need the system running. Installing 
> a new version of KDE is a major task, that can break a lot of things 
> the other users are currently using. You may need to be able to install 
> a new version of the software WITHOUT interrupting the existing service 
> and allow your users to migrate, when the new software has proven to be 
> stable and to satisfiy the needs of the users.
> 
> You cannot achieve this task if you require the libs to be installed in 
> the same location, This is what windows does and what is known as DLL 
> hell. RPATH he the measure to escape this mess. You can install new 
> software and be sure to not break anything for any user during 
> installation and later on.

I disagree with all of that. If new library versions are incompatible,
they should have a different version number. It is quite acceptable and
common to have multiple versions of a library in /usr/lib. For example
it is no problem to have /usr/lib/libgeda.so.20 and
/usr/lib/libgeda.so.22.

If you install new software, it will either upgrade the existing
libraries if they are backwards compatible (hence no effect on the
existing installation), or supply a different filename. Anything
different is broken.

If you want to install two versions of gEDA, you can put them in
different directories and add both to /etc/ld.so.conf. There is no
problem as the libraries have different versions.

> >I think you have no idea what you are talking about.
> 
> If you think, binary distribution is the way, open source software 
> should be distributed, you do have IMHO no idea of open source 
> software.

Whatever.

You haven't convinced me that RPATH solves any problem that is not
solved by /etc/ld.so.conf (for admin-installed software) or
LD_LIBRARY_PATH (for user-installed software).


Hamish
-- 
Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>