gpsd-dev
[Top][All Lists]
Advanced

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

[gpsd-dev] LIBPATH Overrides Revisited


From: Fred Wright
Subject: [gpsd-dev] LIBPATH Overrides Revisited
Date: Sun, 18 Dec 2016 19:55:42 -0800 (PST)

Way back when, I raised the issue of the questionable "LIBPATH='.'" items
that appear on many of the build targets.  At the time, one of the ill
effects was to break dbus linking on most platforms, though that's
subsequently been fixed by another change.  I think it still may break
certain cross-building cases due to undoing the addition of the
sysroot-based library path.  This is subtle, because in principle,
specifying the sysroot option alone is supposed to cause the right
libraries to be used, but I've seen cases where that didn't work and an
explicit -L is needed.  I haven't constructed an actual failing ases for
this, but I still consider the LIBPATH overrides to be suspect, as well as
being a bunch of unnecessary clutter.

I did some digging into the history, and found that those were added as
part of commit 6e1d6bd6, whose main purpose was to eliminate the
dependency on chrpath.  The one improvement I'm able to observe from this
change is that it was previously necessary to set LD_LIBRARY_PATH (or
equivalent) in order to test uninstalled code, and that's no longer been
the case afterward.  But the actual reason for this has nothing to do with
LIBPATH; it's due to the fact that 6e1d6bd6 switched from dynamic linking
to static linking.  My guess as to what may have happened is that the
LIBPATH overrides were an attempt to make the dynamic linking case work
without chrpath, but when it didn't work, Eric threw in the towel and
switched to static linking, without removing the now-pointless overrides.

It would probably be a good idea to revisit the dynamic linking issue at
some point, since it does have some advantages, but that would have to
take into consideration how to test uninstalled code (perhaps by setting
LD_LIBRARY_PATH in the test setup).  Meanwhile, I see no benefit and
perhaps some harm in keeping the LIBPATH overrides, particularly given
that with static linking, the choice of library paths has no long-term
effects beyond building.

I've (again) verified that a version with all the LIBPATH overrides
removed passes "build-all check" on 8 different OSX versions, two Linux
versions, FreeBSD, OpenBSD, and NetBSD.  So unless someone can think of a
reason to keep them (which hasn't happened in previous discussions), I'll
take them out.

Fred Wright



reply via email to

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