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: Mike Frysinger
Subject: Re: [gpsd-dev] 3.11 release is imminent
Date: Mon, 13 Jan 2014 16:00:43 -0500
User-agent: KMail/1.13.7 (Linux/3.12.1; KDE/4.6.5; x86_64; ; )

On Saturday 07 December 2013 08:45:28 Greg Troxel wrote:
>   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.

i think this is making a lot of invalid assumptions.  while /usr/lib is common 
for many architecture ABIs (like i686 32bit), it is not for a good number of 
ABIs.  this isn't specific to Debian or Gentoo or any distro.  the upstream 
gcc/glibc projects themselves default to a different multilib dir:
        x86_64 /usr/lib64
        x32 /usr/libx32
        ppc64 /usr/lib64
        mips/n32 /usr/lib32
        mips/n64 /usr/lib64
this is by no means an exhaustive list, just illustrative.

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

i don't think gpsd should be in the business of trying to guess what the right 
value is.  autoconf doesn't and it's not a problem.

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

putting -L$libdir into the .pc file is fine.  a lot of packages do this.  pkg-
config itself is smart enough to strip that out as needed.

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

the rpath flag does not belong.  imo, if someone uses a non-standard path, then 
it is their problem to configure their system to locate it on the fly.  very 
very few package build systems out there try to do this for the user, and so 
far, every one that does ends up just causing way more of a mess and waste of 
developer time than is worth the gain.
-mike

Attachment: signature.asc
Description: This is a digitally signed message part.


reply via email to

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