[gpsd-dev] Purpose of LIBPATH Overrides

[Fred Wright]

In getting the build to work in the MacPorts environment, first for 3.15
and then for 3.16, I ran into link errors where libdbus-1 wasn't being
found.  I tracked this down to the "LIBPATH='.'" overrides that appear in
many of the build calls, from commit

        6e1d6bd6f51b3a66de029792433dcbfc9fe4a048

The LIBPATH value set up prior to these overrides includes the current
path as added by the following SConstruct line (515 in 3.16):

    env.Prepend(LIBPATH=[os.path.realpath(os.curdir)])

If dbus_export is true, it's also extended by line 588:

        env.MergeFlags(pkg_config("dbus-1"))

(In builds with sysroot specified, it's also expanded by line 304, but
that's not applicable here.)

The resulting path works fine, but when overridden with "LIBPATH='.'", it
lacks the proper path for libdbus-1 (at least in the MacPorts case).

On most platforms, libraries such as dbus get installed into the system
library area, which is normally searched by default, so the overrides are
a don't care.  But since MacPorts tries to stay as independent of the OSX
system libraries as possible, the dbus library goes into the MacPorts
"system" library area (/opt/local/lib by default), so the override
matters.

Since the current directory appears ahead of the dbus path in the
constructed LIBPATH, the overrides can only make a difference for a
library which:

1) Does not exist in the current directory

2) Does exist in the dbus (or other similarly set up) library area

3) Does not exist in the system library area

On most platforms, conditions 2 and 3 are mutually exclusive.  And in the
one case I'm aware of where they're not, the overrides only break the
build (which works fine when they're removed).  So the question is, what
useful purpose, if any, is served by those overrides?

It's also worth noting that cross-building with the sysroot option is
probably broken for the same reason.

I didn't file a bug for this in case I'm missing something.

Fred Wright