gpsd doesn't fully use the right compiler

[michaelld (Michael Dickens)]

I'm trying to build gpsd on OSX 10.14, and find that it doesn't fully use the compiler 'port' wants it to. Please see the attached build log.

[michaelld (Michael Dickens)]

From the attached build log:

:debug:build CC='/usr/bin/clang -arch x86_64'

[snip]

:info:build Obtaining Python config vars... ok
:info:build WARNING: Python too old: gps/aiogps.py will not be installed
:info:build Python module serial (pyserial) found.
:info:build {'OPT': '-DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes', 'BASECFLAGS': '-fno-strict-aliasing -fno-common -dynamic', 'CC': '/opt/local/bin/clang-mp-9.0', 'CXX': '/opt/local/bin/clang++-mp-9.0', 'SO': '.so', 'LDFLAGS': '-L/opt/local/lib -Wl,-headerpad_max_install_names -L/opt/local/lib/db48 -Wl,-syslibroot,/Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk ', 'LDSHARED': '/opt/local/bin/clang-mp-9.0 -bundle -undefined dynamic_lookup -L/opt/local/lib -Wl,-headerpad_max_install_names -L/opt/local/lib/db48 -Wl,-syslibroot,/Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk ', 'CCSHARED': '', 'INCLUDEPY': '/opt/local/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7'}

[snip]

:info:build /opt/local/bin/clang-mp-9.0 -o packet-py_2_7_17_final_0.so -c -fno-strict-aliasing -fno-common -dynamic -fPIC -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I/opt/local/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7 packet.c

[snip]

:info:build packet.c:33:10: fatal error: 'sys/types.h' file not found
:info:build #include <sys/types.h>
:info:build          ^~~~~~~~~~~~~
:info:build 1 error generated.
:info:build scons: *** [packet-py_2_7_17_final_0.so] Error 1

[fhgwright (Fred Wright)]

I'm aware of that bug in GPSD, and was hoping that the band-aid compiler-selection hack I'd put in would work until it could be fixed properly, which I've already determined isn't trivial. At the time, it was only failing on 10.6, and it built successfully on 10.5-10.15 with the hack applied.

I attempted to assign this ticket to myself, but I don't have permissions to do that.

[fhgwright (Fred Wright)]

Build of gpsd on fw's Mac Pro with Xcode 10.3, OS 10.14, and buildmakejobs=1

[fhgwright (Fred Wright)]

Build of gpsd on fw's Mac Pro with Xcode 11.3, OS 10.15, and buildmakejobs=1

[fhgwright (Fred Wright)]

I finally had a chance to look at this, and I can't reproduce it, but I have an idea as to why. Your (michaelld's) system is running Xcode 11.3 on 10.14, while here I have 10.3 on 10.14 and 11.3 on 10.15. Both of the latter cases build with no issues. I've attached logfiles of both successful builds, run with buildmakejobs=1 for consistency in the ordering.

It seems that Apple supports Xcode 11.x on OS 10.14, but doesn't encourage it, in the sense that it's not automatically offered by Software Update. The buildbots are currently running 10.3 on 10.14, so I wouldn't expect to see the trouble there.

The basic problem in this area is that the gpsd build procedure (up through the last release) extracts a bunch of build configuration information from the Python it's targeting, and uses that to build the compiled extension. This can fail for various reasons related to inconsistencies between the Python C compiler (the one used to build Python itself) and the main C compiler used for gpsd itself. Fixing that in the upstream gpsd code has been on my todo list for a while, but meanwhile, the whole approach to the compiled extension has changed upstream, so that the problem no longer exists. However, it's too big a change to be reasonable as a patch, so the proper fix will have to wait for the next release. If it were a widespread problem, then it might be fixable with additional compiler-selection tweaks, but so far that doesn't seem to be the case.

The CC value returned by the current Python2.7 is /usr/bin/clang, suggesting that the command-line tool package is probably involved here. I'd check to make sure that there isn't a version mismatch between CLT and Xcode, since that would be troublesome in general, and is an obvious thing to fix. If not, then there might be a workaround by specifying whitelist/blacklist stuff on the command line.

If this bug is just due to a CLT mismatch, I'd close the ticket. If it's not, but is only due to a fairly unusual setup, then I'd leave the ticket open but lower the priority.

BTW, you're also running a pre-release version of base, which complicates comparing logfiles.

[fhgwright (Fred Wright)]

As stated in my previous comment, this aspect of the build procedure has completely changed, so this bug (which I could never reproduce myself) should be fixed now. I don't have access to close it myself.