gpsd-dev
[Top][All Lists]
Advanced

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

Re: [gpsd-dev] [PATCH] Remove hard-coded LIBATH='.'. It destroys all the


From: John Hein
Subject: Re: [gpsd-dev] [PATCH] Remove hard-coded LIBATH='.'. It destroys all the hard work done by calling pkg-config earlier.
Date: Tue, 16 Feb 2016 08:56:25 -0700

Fred Wright wrote at 17:36 -0800 on Feb 15, 2016:
 > 
 > On Mon, 15 Feb 2016, Fred Wright wrote:
 > > On Mon, 15 Feb 2016, John Hein wrote:
 > >
 > > > Otherwise, you can get link errors like the following if some libs
 > > > are not in the compiler's default library search path:
 > > >
 > > > /usr/bin/ld: cannot find -ldbus-1
 > > [...]
 > >
 > > Seems like deja vu all over again. :-)
 > >
 > > Same thing as I posted earlier, though mine also made some whitespace
 > > adjustments in the process.
 > >
 > > See the macports branch in my GitHub:
 > >
 > >    https://github.com/fhgwright/gpsd
 > 
 > More specifically:
 > 
 > https://github.com/fhgwright/gpsd/commit/9409e215e08b242ccc0ccce8ba5c5495687c3585
 > 
 > The main issue blocking this is figuring out why all those LIBPATH='.'
 > overrides were in there in the first palce.
 > 
 > Fred Wright
 > 

As you know, it was committed here:

===========
commit 6e1d6bd6f51b3a66de029792433dcbfc9fe4a048
Author: Eric S. Raymond <address@hidden>
Date:   Tue Mar 31 09:55:06 2015 -0400

    Eliminate chrpath as a build dependency
===========

No further context found that I could see.  And, probably like you,
I did some archeology to understand why LIBPATH='.' was added.

It's certainly not needed to get the project directories into the lib
search patch since it seems that scons puts '.' in the front of
LIBPATH by default.

One reason I can think of to force LIBPATH='.' only is to make sure
you only pull in libs built by the project.  This means you'd have to
build all dependencies (e.g., dbus) as part of the project.  You might
even want to link with -nostdlib in some more extreme cases.

Some projects do offer the option of using a "system" lib vs an
internal version of the same lib.  It's usually when the project wants
to use a particular "stable" version (API- & feature-wise) or to
account for platform differences (e.g., perhaps zlib features varying
widely when building for, say, HP-UX vs linx).

In any case, I don't see support in gpsd for any such "internal" lib
building.

It's not clear to me why the LIBPATH='.' was added in the first place.
Perhaps I'm missing the underlying reason.



reply via email to

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