[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: gEDA: gschem rpath autoconf test
-----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 mario@klebsch.de
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-----