-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi!
Am 26.01.2005 um 22:47 schrieb Hamish Moffatt:
On Tue, Jan 25, 2005 at 11:44:23PM +0100, Mario Klebsch wrote:Am 25.01.2005 um 11:30 schrieb Hamish Moffatt:It prevents you from moving libraries without recompiling the programs that use it.
No, it does not. In fact, you can always use LD_LIBRARY_PATH or modify your /etc/ld.so.conf.
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.
LD_LIBRAARY_PATH not overriding RPATH would IMHO be broken.
Debian has moved libraries before during big
transitions; we moved all of the libc5-using libraries to
/usr/i486-linuxlibc1/lib. If our programs were compiled with RPATH, we
would have had to recompile all of those as well.
No, we would not have had to recompile the programs, even those with RPATH.
Why not? Do you think we should have set LD_LIBRARY_PATH to add the /usr/i486-linuxlibc1/lib directory?
I did it and I did not have to recompile any of my old executables.
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.
Why would we do that? In that case, why would we bother to link the path
into the binaries in the first place?
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.
You may not care about this as long as you are the only user of your system, but with 50, 200 or even 1000 users on your system, this will be an issue.
You see, RPATH has no benefit at all to a distribution.
Of course, the needs of distribution builders often require them no not use PATH, but open source programs usually are not written to satisfy the need of distributors but of the users. If they would only address distributors, there would be no need to publish soruce code at all.
It would only be useful to an individual user unable to install into system directories (/usr/lib or /usr/local/lib) who is too lazy to set LD_LIBRARY_PATH.
There are lots of other reasons to use RPATH. Wether it is used is not a decision of the program using a lib, bau a decision of the one, installing a lib.
The Linux dynamic linker (ld.so) HAS a search path facility (with the path listed in /etc/ld.so.conf); USE IT.
rm does accept -rf and / as aruments. USE THEM.
What?!
Not every feature, that exists, has to be used to do everything it possibly can do. There are several features out there, that are usefully used only under very specuial circumstances. rm -rf / ise one of these features, putting all directories containing libraries in /etc/ld.so.conf is just anotehr example.
I do not want to force anybody to use RPATH, I just want ./configure to reliably do what it is supposed to do,namely find out the system specific settings required to compile a software package. If ROPATH is reqired on the system probed by ./configure. ./configure should find out this fact reliably. If RPATH is not needed on a system, ./configure should also find out, that no RPATH is neededm with teh same reliability. Present state is, that ./configure often failes to detect the need of RPATH and it is near to impossigle to compile a package, when ./configure failes.
I am willing to do my part in achieving this goal, but I must admit, that it is much more easy to me to hack Makefiles and C source code that debugging these endless long ./configure scripts.
As I wrote earlier, removing RPATH from an executalbe is a simple task.
Just a single byte has to be changed to 0.
What? So Debian should edit all our binaries to remove RPATH like this?
If they see no other way to create executable without RPATH, yes. They do lots of stuff to create their packages, removing RPATH would just be one more step, easily being automated, either during package creation or even during package installation. As long as a sufficient long placeholder is included in the executable, even changing rpath during installation is not really an issue. Distributers may have special requirements, but they also do use special tools.
As long as distribution makers create software for their distribution, they can put in there anything they like. As long as I don't use this distribution, I don't care, When I use it, it will simply work.
But we are talking of software supposed to be more or less portable. As long as there are systems, that require RPATH for at least some libs, the automated configure process should detect this situation and cope with it. ./configure being rock solid is to me far more important than the requirements of some software distributors. We already reached a point, where ./configure far to often failes, because the probes are not rock solid. This is not the way, ./configure was meant. I still remenber the first packags havon a ./configure, and those configure scripts were excellent work. But today, ./configure often is just endless pain.
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.
73, Mario
- -- Mario Klebsch [EMAIL PROTECTED]
PGP-Key available at http://www.klebsch.de/public.key
Fingerprint DSS: EE7C DBCC D9C8 5DC1 D4DB 1483 30CE 9FB2 A047 9CE0
Diffie-Hellman: D447 4ED6 8A10 2C65 C5E5 8B98 9464 53FF 9382 F518
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)
iD8DBQFB+YmAMM6fsqBHnOARAvaSAJ0b/qZDTNycSdpZ9bRU9o4cHP3oUgCg3DRo 6vq6VvVHgm1zKM4UZ2+DMEY= =9Eh8 -----END PGP SIGNATURE-----
