Re: ✘ Release blockers?

[Fred Wright]

On Mon, 16 Dec 2019, Gary E. Miller wrote:
> On Mon, 16 Dec 2019 17:33:44 -0800 (PST)
> Fred Wright <address@hidden> wrote:
>
> > > Which build failure do you exactly mean?
> > -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)
>
> Odd.
>
> > It looks like this only happens with clang and not with gcc, which is
> > why it doesn't affect all platforms.
>
> We do test on clang.  I test on osX which uses clang.  But I see I do not
> have Qt enabled.  Not sure how to do that on a mac.

If you have MacPorts installed, just install the qt4-mac port.  At one 
time I also had builds with Qt5 working on the Mac, but something changed 
that broke it since then, so for now it's Qt4-only.

> > 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 only Qt thing gpsd builds is a simple test case.  No known clients.

Yeah, I know, but at least the simple test should build and run.

> > 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,
>
> We used to do something similar, it broke other things.

It's worked in all the cases I've tried, and it just mimics what was 
already being done for several other modules.

> Please do some tests, time is running out before the next release.

I've pushed several commits to fix a number of problems.

> > as well as looking into a different failure that only
> > shows up on OpenBSD.
>
> Don't keep us in suspense.

Fixed now.

> > 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.
>
> Could be.  AFAIK, only some Power CPUs have big-endian modes.  They
> should die...

All POWER and PowerPC processors are natively big-endian.  Some (but not 
all) of them have a little-endian mode, which may or may not be supported 
by a given OS.

> If you could do this, and send the results that would help a lot:
>
>  # ./regress-driver test/daemon/garmin18x-bin.log

I'll look into it myself first, since I can actually reproduce it here.

One thing that isn't strictly a regression, but has been rearing its ugly 
head lately, is that crock where it thinks it needs to build the Python 
extensions with the exact same C compiler as was used for Python itself. 
If that compiler isn't available, or isn't "configuration compatible" with 
the normal C compiler, then the extensions fail to build.  I'd like to try 
to fix that before the release.

On Tue, 17 Dec 2019, Gary E. Miller wrote:
> On Tue, 17 Dec 2019 22:05:51 +0300
> Paul Fertser <address@hidden> wrote:
>
> > On Tue, Dec 17, 2019 at 10:41:09AM -0800, Gary E. Miller wrote:
> > > > On Mon, Dec 16, 2019 at 06:00:40PM -0800, Gary E. Miller wrote:
> > > > > Could be.  AFAIK, only some Power CPUs have big-endian modes.
> > > > > They should die...
> > > >
> > > > Many popular SOHO routers/APs are using MIPS BE SoCs (e.g. all
> > > > Atheros/QCA devices) and people run gpsd on them with OpenWrt.
> > >
> > > Yes, but I believe they all run in little-endian mode.  Power can
> > > run
> >
> > Mediatek-based devices run in LE [0], Atheros/QCA in BE [1] (notice
> > mipsel vs. mips). There's also Lantiq which is also BE [2] and is
> > basically the only supported architecture with xDSL drivers.
>
> Nice to know, but without someone to test on something BE nothing gpsd
> can do.
>
> Can you test BE for us?

That's exactly what I'm doing here.

> > Broadcom is BE too (but they suck).
>
> Broadcom never gives us the doc we need, so cross them off.

Yep, Broadcom is one of the worst companies on the planet when it comes to 
making documentation available.  Raspberry Pi users, take note. :-)

Fred Wright