Re: [gpsd-dev] 3.11 release is imminent

[Greg Troxel]

Mike Frysinger <address@hidden> writes:

> what to cross-compile ?  `ldconfig` will tell you absolutely nothing useful.  
> your host system might be using /usr/lib, but the target could be using 
> /usr/lib64.  or vice versa.

This is an important point; looking in the host systems's ldconfig files
is broken.

I think there's still either confusion or a lack of precision in this
discussion.  To try to fix this, I think what's going on is (starting
From description and becoming normative):

  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.

  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.

  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.)

  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.

  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.

  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).

  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.


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).

pgpst9PnpQLG4.pgp
Description: PGP signature