Re: [gpsd-dev] The mess around SHM export keys is solved

[Hal Murray]

scons check is working for me now when gpsd is running.  Thanks.

On NetBSD, I'm now getting:

Processing test/daemon/GPSmap-76S.log
gpsd:ERROR: unable to connect to the DBUS system bus
Processing test/daemon/ac12.log
gpsd:ERROR: unable to connect to the DBUS system bus
...

Did you make a deliberate change in that area?

Works on FreeBSD

----------

> It was a couple of minor coding errors on my part, which I would have
> spotted sooner if Hal had been running the code he thought he was.  As it
> was, some bug reports sent me haring off in a wrong direction. 

> The regression-test driver already sets LD_LIBRARY_PATH to include .

Doesn't that mean it should use the right libraries when I forgot to set 
chrpath=yes?

What was the case where I misled you by running the wrong code?

But maybe it really was running the wrong libraries...

---------

I tried to test chrpath=no
I hacked the top of regress-driver to print LD_LIBRARY_PATH
It seems to be set correctly.

But things hang on the first test and the timer doesn't go off.  ???

sys linux2 platform Linux-3.18.6-200.fc21.i686-i686-with-fedora-21-Twenty_One:
 WRITE_PAD = 0.00000

./gpsd: RPATH=//usr/local/lib
LD_LIBRARY_PATH: /home/murray/gpsd/work

Testing the daemon...
Processing test/daemon/GPSmap-76S.log

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND   

12860 murray    20   0   13128   9596   6216 R  99.0  0.5  21:03.08 python    

12861 murray    20   0    3356   1620   1504 R  11.0  0.1   2:14.90 sed       




Here is a chunk from ps while it is hung.  I don't see a gpsd in here.
27919 pts/0    S+     0:02 /usr/bin/python /usr/bin/scons check
27967 pts/0    S+     0:00 sh -c :; ./gpsfake -T; ./regress-driver 
test/daemon/*
27971 pts/0    S+     0:00 /bin/sh ./regress-driver 
test/daemon/GPSmap-76S.log t
27983 pts/0    R+     3:06 python /home/murray/gpsd/work/gpsfake -s 38400 -1 
-p
27984 pts/0    S+     0:19 sed -e /^gpsd:/d -e /^gpsfake/d -e /GPS-DATA/d -e 
/WA

I don't see a gpsd in there.

I started gpsd by hand:
address@hidden work]$ LD_LIBRARY_PATH=/home/murray/gpsd/work ./gpsd -n -N -S 
10003 /dev/ttyUSB2
gpsd:ERROR: shmget(0x47505344, 8060, 0666) for SHM export failed: Invalid 
argument
gpsd:ERROR: device open failed: Device or resource busy - retrying read-only
gpsd:ERROR: read-only device open failed: Device or resource busy
gpsd:ERROR: initial GPS device /dev/ttyUSB2 open failed
address@hidden work]$ ^C
(There is a production gpsd running.)

lsof in another window said:
address@hidden work]# lsof | grep libgps
gpsd        696        nobody  mem       REG        8,4    121136    1345880 
/usr/local/lib/libgps.so.22.0.0
gpsd        696        nobody  mem       REG        8,4    385788    1345881 
/usr/local/lib/libgpsd.so.22.0.0
gpsd        696   700  nobody  mem       REG        8,4    121136    1345880 
/usr/local/lib/libgps.so.22.0.0
gpsd        696   700  nobody  mem       REG        8,4    385788    1345881 
/usr/local/lib/libgpsd.so.22.0.0
gpsd      28094        murray  mem       REG        8,4    121136    1345880 
/usr/local/lib/libgps.so.22.0.0
gpsd      28094        murray  mem       REG        8,4    385788    1345881 
/usr/local/lib/libgpsd.so.22.0.0
address@hidden work]# 

So it's getting the wrong libraries.

If I smash the RPATH in ./gpsd to garbage, lsof shows it using the right 
libraries.

Does LD_LIBRARY_PATH get appended to RPATH rather than prepended?

It fails on tom if you need a test case.


-- 
These are my opinions.  I hate spam.