gpsd-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [gpsd-dev] 3.11 release is imminent


From: Bernd Zeimetz
Subject: Re: [gpsd-dev] 3.11 release is imminent
Date: Mon, 13 Jan 2014 00:50:24 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20131103 Icedove/17.0.10

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256


> The use of RPATH for other than /usr/lib is the standard approach, as 
> measured by types of systems.  However Debian (and Gentoo?) depart from
> that, so both approaches need to work.

Where does Debian depart from that? If you put something in a directory which
is not in the search path of the linker, you need rpaths. rpaths are not bad
if you let them point into a directory which is owned by root:root and not
world writable - for example putting libgpsd (with the d!) into /usr/lib/gpsd
is an option I thought about already, using an rpath to point gpsd and friends
to it. but due to the mess with rpaths (and the need to remove them again to
ensure that there is not a fucked up rpath pointing to /tmp/something in
/usr/sbin/gpsd), I did not bother yet.

> gpsd is given a prefix, and from that derives a variable that would be 
> called libdir by autoconf.  In the standard case that's $prefix/lib, but on
> some Linux systems it's $prefix/lib64.  Presumably gpsd's build machinery
> already has to figure this out, because libgps needs to be installed there.
> Or perhaps systems that doesn't use libdir=$prefix/lib have to set
> --libdir=$prefix/lib64 explicitly.


or /usr/lib/x86_64-linux-gnu and other triples. There are ways to detect the
proper settings as autofoo and cmake just handle it fine. No idea what scons
knows there...

> gpsd creates pkgconfig files.   These have a --libs built in, which should
> have (in the normal case) -lgps -L$libdir -Wl,-R$libdir unless prefix is
> /usr, in which case L/R are presumed to be unnecessary.
> 
> gpsd reads (or should) pkgconfig files for depeendencies, and perhaps 
> foo-config programs for dependencies that are using pre-pkgconfig 
> mechanisms.  Those get the equivalent of "pkg-config foo --libs", which are
> inserted: 1) in the build of programs that gpsd installs that use that
> dependency 1) in the build of python modules that gpsd installs that use
> that dependency 2) in the build of libraries that gpsd installs that use
> that dependency It is clear to me that gpsd (or anything else) has no
> business mucking with the libs returned from pkgconfig for dependencies.
> (Systems that choose not to use RPATH will have adjusted those dependencies
> not to report rpath in --libs.)

The pkg-config output should have everything you need to compile against a
library on that system. If the library is not i a default search path or needs
other special compiler foo, it needs to be in there. If its not in the
pkg-config file, its a failure of the distribution and nothing gpsd needs to
take care of or work around.


> Therefore, the only question on the table is whether gpsd should put 
> -L$libdir and -Wl,-R$libdir in the generated libgps.pc files. Everything
> else follows directly from this.

In case you use folders which are not in the standard linker search path, why 
not.
But please remember that -R won't work on linux, you'll need -rpath and friends.


> It seems clear that for prefix=/usr, -L and -R should be omitted; it's 
> universal that systems search the $libdir that corresponds to /usr.

Not sure how /usr/local is handled on other distribs, on debian /usr/local/lib
is in the default search path.


> It seems clear that some desire a "no rpath" option.  That should drop the
> -R from libgps.pc and libgpsd.pc (and thus in the link of eg. gpsd, but not
> remove any -R that came from e.g. libusb).

Definitely - if there is no rpath necessary, don't ship one - especially not
having one pointing to user writable directories.

> The default should be to add -R unless prefix=/usr, because that's the 
> standard approach.
> 
> Because this is only about "do we add -R for gpsd's $libdir", there is no
> need to configure a list of lib paths to avoid adding RPATH for.


> The approach I've outlined has no magic, and should not have surprising 
> results.  Debian must be used to removing RPATH (just as pkgsrc is used to
> fixing bashisms in shell scripts) and I'd expect that a --rpath=no scons
> option would be pretty easy to stick in a config file.  And if prefix=/usr,
> then no rpath would be added, so this isn't even necessary.

Seriously, it is a shame that discussion is necessary at all - libtool handles
this sanely for some years now (yeah, around ~2001 compiling with -R on
solaris was badly broken...) - and scons brings us the same issues just years
later? Thats a big WTF for me.


> Separately, the release process feels unstable.  Changing this sort of 
> thing is a major change with non-obvious consequences on platforms that 
> weren't tested on.  There should be at least a week between a change and 
> release; the current culture tends to discourage people who can't or don't
> want to pay attention daily.  There aren't regression tests to determine if
> this is ok (or rather scons check doesn't run them on s stable of
> platforms).

strong ack! I tend to run into all kinds of troubles when building a new
release for Debian. I'd appreciate rc/beta/whateveryouliketocallthem releases
before the "real" one goes out. I can easily ship (even broken stuff...) in
experimental to test things and to build the release on all arches. For
example 3.10 came with regressions in the regression tests on various arches
and nobody notices before the release went out...

- -- 
 Bernd Zeimetz                            Debian GNU/Linux Developer
 http://bzed.de                                http://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Icedove - http://www.enigmail.net/

iQIcBAEBCAAGBQJS0yo4AAoJEOs2Fxpv+UNfhXUQAKcqDM+tq34Teii5K3YcQn0x
N8AmLszQeFPRmj8vT3OjYXaVN4Juv1ne10JjPaGUCvoUN3OHUyXDsTnj+dEPRkQc
mP85SgM2Ubp5Bk4nFnE7/3ySIdPQgQnhCvUsBndOO8leOx0c9JIHdi5Lm5EetG5M
qOio+IjrobBmeWmV9l4LOYjNYIBvecnn0AYDfHjxV3INnykxMP5OvrzYpNzgTZ8D
QM5WQPQOOCtp78NyU7mX6ElKqiWYKzwr9iY1NmkIxcnKBaKezVtSGGfXGpj6dc8W
+Rx7nwsQZQ7wa9xtDurcp8mz9SDtxXcK8w6Aewdg7cmugJ8GabcfHn58B52+6c2c
4clXWMk73+IZso8x2/ZW4Rcxvk6S/rP73WhEDGFzR40gpkILFafowcES5sZYufz+
gJJSOkZsSTFCsYw9iTicCaa+67OmqM/m9GO7JQg+jKVeMhAxx7xt+l1rKXoh3Ey+
A6lSoGA5CONnFvlbAbptS7pDGopLknB11o9rnfy1JOIiG2qltobOIYiEvQW7nG99
9QEYvh0clu4L0J/dPZJbIAYt8C9Erok7eQXYS83cFtFdDnQuw2UEgeuL9WAkLOo0
DcMbgCP9dHlFJ60rs58nKfc6ALSvGgFHx5186M5oGJQS5BRb65MaNLjQgXe9l4xT
sEPSnyeQKlGlIY8RF80T
=zgUn
-----END PGP SIGNATURE-----



reply via email to

[Prev in Thread] Current Thread [Next in Thread]