-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi!
Am 19.01.2005 um 08:10 schrieb Bernd Jendrissek:
The opposite is true. Without rpath, upgrading a library replaces an existing one. with rpath I can safely install a new version at a different location and I do not risk to break anything.
So why install a new version at all, if all you notice is that it "breaks" things?
Because you often notice the problems after installing the new version. If you want to play safe (or you have to play safe, because there are different users on the system , that reley on thinks working; UNIX is a multi user system), you have no choice but to install new software without interfering the installed software base. This is not possible if the new installation replaces the old one.
Ah, but then *everything else* that uses your library, or every library to which your executable links, must *also* use rpath.
As I wrote in a different mail, it is a decision of the person, installing a lib, wether RPATH is required or not to use the lib on this specific installlation.
Anyone writing programs, that rely on excternal libs, is not to decide, wether his programs should use RPATH or not.
But once again, I can understand why distribution makers argue different.
Their reasons are not magically counter to the interests of non-distributors.
IMHO rpath is evil purely because it restricts my options - permanently!
You are free to install your libraries in a way, that no rpath is required and noone will fource you to use rpath. If you choose a prebuild distribution, you trust the distribution builders have taken that decision for you. Since noone forces you to use rpath, please be as nice as to not force anybody to NOT use it.
configure should first check, wether the compiler accepts any rpath flags (-R, -Wl,--rpath, LD_RUN_PATH, ...). If the compiler does, configure should supply the approriate rpath arguments to the compiler for each -L-argument used. This is letting ./configure plaing safe, since it does no harm to the probe program.
When the tests show, that the libs are available and working, configure should check for each -L, wether it can be omitted from rpath.
Or, you could just let libtool figure out all this messy stuff?
YAMTTBT (Yet Another Magic Tool, That Breaks Things) :-(
Unfortunately, hunting bugs in ./configure scripts is not the only thing you lern, when you choose to install libs in non standard locations (What the hell is a well accepted standard location for libgeda???), but also to dig through all those libx.la-files created by libtool. :-(
There are only a few things that must be known to be able to compile a program using a random lib: additional arguments required on the compilers command line (e.g. -I...., -D...., -U... ,...) and additional arguments required on the linkers command line (-L..., -R..., -l...). Why is it so hard to specify them today? It is a real pain to fix almost everything, ./configure creates. :-(
I do not mind having ./configure guessing the required arguments and I even mind less, when ./configure guesses the required arguments correctly, but when ./configure failes, it should be easy to manually specify the correct arguments.
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)
iD8DBQFB7t3CMM6fsqBHnOARAvHVAKCMr6X0F2Ir/T+vwCmVR1wY88B01ACfUnd0 ysrdktgHMCftxf+qVsw7gAU= =oPBD -----END PGP SIGNATURE-----
