gpsd-dev
[Top][All Lists]
Advanced

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

Re: ✘gpsd release coming


From: Greg Troxel
Subject: Re: ✘gpsd release coming
Date: Tue, 04 Aug 2020 12:39:25 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (berkeley-unix)

"Gary E. Miller" <gem@rellim.com> writes:

> On Tue, 04 Aug 2020 11:44:53 -0400
> Greg Troxel <gdt@lexort.com> wrote:
>
>> It seems obvious to me that the gps python programs should be loading
>> the packet library by the full pathname that was chosen at "scons
>> build" time, without relying on anything in the environment, so that
>
> Which breaks "scons check", is a large change from prior behavior, and
> breaks other scenarios.

Sure, obviously for later.

autoconf/libtool always had this notion of 'make' pointing the binaries
at the build tree, and 'make install' repointing them.

> The algo is:
>
> Check in GPSD_HOME
>
> Check in current working directory
>
> proceed with dlopen() defaults (LD_LIBRARY_PATH, etc.) as all
> other shared libraries do.
>
> Without the GPSD_HOME and cwd priority then scons check does not check
> the current build but will fail if not already installed and if already
> installed it checks the 
>
> It might be possible to mung the GPSD_HOME and cwd into LD_LIBRARY_PATH
> but then you run into a mass is distro/OS quirks.

So it would seem that

  if some magic GPSD_TEST_UNINSTALLED env var is set, look in current
  directory (only)

  if not, load the right path (only)

would be a good plan.  This is just like what happens, or should happen,
when program have to exec a companion binary.

I wonder if dlopen respeects RPATH; it seems like it should.  I run with
no LD_LIBRARY_PATH and gpsd si in /usr/pkg which is not in the default
system path.

Attachment: signature.asc
Description: PGP signature


reply via email to

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