[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 29.01.2005 um 14:48 schrieb Hamish Moffatt:
> 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.
If an admin snstalls geda, on a system, that already has geda
installed, e.g. geda-20030223 in /opt/geda-20030223, geda-20030901 in
/opt/geda-20030901 and now wants to install geda-20041228 into
/opt/geda-20041228, what in your opinion, shod this admin put into
/etc/ld.so.conf?
You cannot assume only a single version of geda (or any other
non.system package) being installed on a system.
>> 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.
How do you know, a new version of a library is compatible? even
different compiles produced of the same source code can be incompatible
to each other. You only know, that two libs are compatible, if you have
carefully checked compatibility.
> 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.
So, who will take care of version numbers? I very much prefere to ande
different versions by using different paths. There also is another
problem with your versioned aproach: AFAIK, the linker always links to
the newest lib. It would be difficult to fix a bug in an older version,
since when recompiling later you accidently can ling against the newer
lib. You are sure to avoid this mess, when you clearly separate
different versions into different filesystem subtrees.
> If you install new software, it will either upgrade the existing
> libraries if they are backwards compatible (hence no effect on the
> existing installation),
Who do you know, the new files are backwards compatible, prior to
installing them?
> 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.
Since the library version numbers are supplied by the libraries
makefiles, this aproach will never catch incompatibilites created e.g.
by a new set ob yould tools or different build options.
> 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).
Have you ever administered a system for other users? As long as you are
the only user, you will hardly have any need to use RPATH to make
thing, you cannot achieve by editing /etc/do.so.conf. But as soon as
you are resonsable for keeping the system running as aproductivity tool
for other users and at se same time keep the softer used up to date
without risking the oprations going on, you sool will have no other
choise than to use RPATH (or maybe chroot()).
I have done this for several years, I have seen all those problems
introduced by careless use of LD_LIBRARY_PATH, I have been fallen on my
nose by not cleanly separating newly installed software even after
minimal bug fixes of changes, this all long time before linux even
supported ELF. I know what I am talking about. I learned to always
offer my users a safe way back, when new software is installed. It is
an absolute must, when you administer a system for other users.
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+/X9MM6fsqBHnOARAkRuAJ9Xyk971rc+uTHLGe2LvTlKGYNc3wCdE99u
ED8UzELBrCgwM7qtycCUWA0=
=3fvc
-----END PGP SIGNATURE-----