On Fri, 14 Nov 2025, Gary E. Miller wrote:
On Thu, 13 Nov 2025 20:49:57 -0800 (PST)
Fred Wright <[email protected]> wrote:
I'm finally caught up after the weekend, so I should be able to do
a bunch of testing tomorrow (Wednesday).
Removing the strnlen() fallback broke a couple of old OSX builds, and
I suspect some old BSD builds as well (though I haven't gotten to BSD
yet). The only cost of that code in the cases where it isn't needed
is the one configure test, which doesn't seem like a big enough deal
to break older builds. I'll put it back if you don't object, being
careful not to revert the one unrelated fix that was included in the
same commit.
Could you be more specific? What "strnlen() fallback"? Which commit?
Commit 6cb4d38f removed the strlen() fallback (introduced in commit
e9e15e6e), as well as fixing a bug introduced by commit 27610cbc (not
mentioned in the commit message).
Meanwhile, I've fixed a few warnings, and restored the Qt4 option
(which used to be the default). I don't plan to push anything until
I've finished testing.
For most Qt4 is long dead. scons now looks for Qt5, then Qt4. And the
override was still supposed to work. So please share your fixes before
commting.
No, it now looks for Qt6, then Qt5, and doesn't allow Qt4 at all. Qt4
needs to be handled a bit differently, since it has QtNetwork rather than
Qt4Network.
The history is that gpsd originally only supported Qt4. When I determined
that it could be built for Qt5 just by replacing 'QtNetwork' with
'Qt5Network', I added the 'qt_versioned' option to allow that. The reason
it's called 'qt_versioned' rather than 'qt_version' is because it's based
on the naming convention for 'QtNetwork', though in hindsight that was
probably a poor naming choice.
Between the time that I implemented that and the time that I tried to make
use of it in the MacPorts version by allowing a choice between Qt4 and
Qt5, the Qt5 build stopped working. I didn't bother investigating, and
just punted on the option.
My 10.9 system has both Qt4 and Qt5.8 (the last version for 10.9)
installed. Prior to commit 875fa2da, the default blank qt_versioned chose
Qt4, which still worked. Now, the blank qt_versioned means "choose Qt6
or Qt5", with no option for Qt4. And it still doesn't build for Qt5.8.
The fix I currently have adds '4' to the version list, while also handling
the naming exception correctly. It's still a regression, since with both
Qt5 and Qt4 installed, it prefers the non-working Qt5 to the working Qt4.
That could be fixed by changing the priority order, but that seems like
too much of a kludge. I currently have a local-only patch to make Qt4 the
default, to simplify testing.
In addition, commit 05c53008 made a change to fix Qt6 that broke Qt4 (it's
a don't care for Qt5). I made that conditional on the Qt version.
Qt4 remains available across the full range of platforms, unlike newer
versions.
It might only take a modest amount of work to fix the version selection
and/or the Qt5 build, but that's not appropriate right before a release.
And all the Qt stuff is a big mess in general, for multiple reasons. My
current fix is just a minimal fix to unbreak the Qt4 case.
Fred Wright
