Re: [gpsd-dev] Example code for libgps using shared memory

[Fred Wright]

On Wed, 15 Nov 2017, Gary E. Miller wrote:
> On Wed, 15 Nov 2017 18:44:24 -0800 (PST)
> Fred Wright <address@hidden> wrote:
>
> > > > Anything that requires setting LD_LIBRARY_PATH is broken.  Did you
> > > > rerun ldconfig after the install?
> > >
> > > I disagree.  /usr/local/lib is not in LD_LIBRARY_PATH by default,
> > > and the FHS has us install in /usr/local/llib to not step on system
> > > libraries.
> >
> > You're missing the point.  LD_LIBRARY_PATH shouldn't be used in normal
> > circumstances *at all*.  See, e.g.:
> >
> Uh, no.  read the standard; FHS.

This isn't about FHS; it's about the use of LD_LIBRARY_PATH, which is a
mostly orthogonal issue.

> > http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html
> > http://xahlee.info/UnixResource_dir/_/ldpath.html
>
> Your links are for ssytem stroinstalled libs.

No, they're not.  Read them.

> The case here is for user installed libs that are distinct from distro
> installed libs.

>From a Debian system with GPSD installed from source:
--------------------------------------------------------------------
address@hidden:~# echo $LD_LIBRARY_PATH

address@hidden:~# ldconfig -v | grep -A3 -B3 gps
ldconfig: Path `/lib/arm-linux-gnueabihf' given more than once
ldconfig: Path `/usr/lib/arm-linux-gnueabihf' given more than once
ldconfig: /lib/arm-linux-gnueabihf/ld-2.13.so is the dynamic linker,
ignoring

        libxcb.so.1 -> libxcb.so.1.1.0
        libasprintf.so.0 -> libasprintf.so.0.0.0
/usr/local/lib:
        libgps.so.23 -> libgps.so.23.0.0
        libfdt.so.1 -> libfdt-1.4.0.so
/lib:
        libnss_mdns4.so.2 -> libnss_mdns4.so.2
--------------------------------------------------------------------
Note that it has no problem finding libgps in /usr/local/lib, without
LD_LIBRARY_PATH.

On Thu, 16 Nov 2017, David Huichen Dai wrote:
> On Thu, Nov 16, 2017 at 5:42 AM, Fred Wright <address@hidden> wrote:
>
> > Anything that requires setting
> > ​​
> > LD_LIBRARY_PATH is broken.  Did you rerun
> > ldconfig after the install?
> >
> ​--No, I didn't. I just added the path to the ​LD_LIBRARY_PATH, and ran the
> code in a new terminal.
> I was in a hurry to make the code work, and the first thing occurred into
> my mind was to use the
> LD_LIBRARY_PATH
> ​.​
>  ​
>
> ​​

The shortest path to the cheese isn't necessarily the correct path to the
cheese. :-) Many software bugs are due to failure to appreciate that
concept.

> ​If ​LD_LIBRARY_PATH shouldn't be used in normal circumstances *at all*,
> how could I use the libgps?

If libgps is properly installed before building your program, then simply
including "-L/usr/local/lib" in the linker options should be sufficient to
locate the library directory, both at link time and at run time.

Testing with *uninstalled* libraries may require the use of
LD_LIBRARY_PATH, but that's a special circumstance and not the normal use
case.  And you need to be careful of installing programs built with
LD_LIBRARY_PATH set, since they may inherit a dependency on it.

On Thu, 16 Nov 2017, Michael J. Tubby B.Sc. MIET wrote:

> On my VR2200 Ubuntu 14.04 based ARM box I edited /etc/ld.so.conf and added:
>
>      include /etc/ld.so.conf.d/*.conf
>      /usr/arm-linux-gnueabihf/lib
> *    /usr/local/lib*
>
> and then did an 'ldconfig' ... worked for me but YMMV

It sounds like you ran afoul of this bug (quoted from the HOWTO linked
above):
------------------------------------------------------------------------
The list of directories to be searched is stored in the file
/etc/ld.so.conf. Many Red Hat-derived distributions don't normally include
/usr/local/lib in the file /etc/ld.so.conf. I consider this a bug, and
adding /usr/local/lib to /etc/ld.so.conf is a common ``fix'' required to
run many programs on Red Hat-derived systems.
------------------------------------------------------------------------

And from the same HOWTO document:
------------------------------------------------------------------------
LD_LIBRARY_PATH is handy for development and testing, but shouldn't be
modified by an installation process for normal use by normal users; see
``Why LD_LIBRARY_PATH is Bad'' at http://www.visi.com/~barr/ldpath.html
for an explanation of why. But it's still useful for development or
testing, and for working around problems that can't be worked around
otherwise. If you don't want to set the LD_LIBRARY_PATH environment
variable, on Linux you can even invoke the program loader directly and
pass it arguments. For example, the following will use the given PATH
instead of the content of the environment variable LD_LIBRARY_PATH, and
run the given executable:
  /lib/ld-linux.so.2 --library-path PATH EXECUTABLE
Just executing ld-linux.so without arguments will give you more help on
using this, but again, don't use this for normal use - these are all
intended for debugging.
------------------------------------------------------------------------
(Note that the link in the above text is now broken, but the link I posted
above is a working link to the same document.)

Fred Wright