Re: ✘ Release blockers?

[Fred Wright]

On Sat, 14 Dec 2019, Bernd Zeimetz wrote:
> On 12/14/19 7:33 PM, Fred Wright wrote:
> > > > > 1) The C++ build breakage related to timespec_str.  I already have
> > > > > a tentative fix for that, but just as I was about to test it, I ran
> > > > > into a disk-space issue for my VMs, which I'm in the process of
> > > > > sorting out.  The whole C++ area is pretty much a mess, but at least
> > > > > this can make it no worse than it used to be.
> > >
> > > I am unable to duplicate this.  Is it still a problem for anyone?
> >
> > One needs the qt and/or libgpsmm options to see it.  Those are supposed
> > to be independent, but they seem to have become not so, which is
> > something else that needs investigating.
>
> The CI builds the c++ and qt libraries, same as in Debian. No issues there.
> https://gitlab.com/gpsd/gpsd/-/jobs/378075712
>
> Which build failure do you exactly mean?

Errors like this (excuse the line wrap):

g++ -o libQgpsmm.25.0.0.dylib -dynamiclib -Wl,-current_version,25.0.0 
-Wl,-compatibility_version,25.0.0 qt-ais_json.os qt-bits.os 
qt-gpsdclient.os qt-gps_maskdump.os qt-gpsutils.os qt-hex.os qt-json.os 
qt-libgps_core.os qt-libgps_dbus.os qt-libgps_json.os qt-libgps_shm.os 
qt-libgps_sock.os qt-netlib.os qt-os_compat.os qt-rtcm2_json.os 
qt-rtcm3_json.os qt-shared_json.os qt-timespec_str.os qt-libgpsmm.os -L. 
-L/opt/local/lib -L/opt/local/libexec/qt4/lib -lm -ldbus-1 -ldbus-1 
-lQtNetwork -lQtCore
Undefined symbols for architecture x86_64:
  "_timespec_str", referenced from:
      _libgps_dump_state in qt-libgps_core.os
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see 
invocation)
scons: *** [libQgpsmm.25.0.0.dylib] Error 1
scons: building terminated because of errors.

It looks like this only happens with clang and not with gcc, which is why 
it doesn't affect all platforms.  It also only happens with qt=yes, but 
qt=no is forced if pkg-config can't find QtNetwork, explaining 
non-failures in certain cases.

The fix is just to add timespec_str.c to the list of sources that get 
compiled as C rather than C++ in the C++ build, but I need to fully test 
that, as well as looking into a different failure that only shows up on 
OpenBSD.

I'm also seeing a new regression test failure with garmin18x-bin.log on 
the PowerBook, which I'll look at after the other issues.  This might be 
an endian bug.

Fred Wright