gunits @2.24: error: ‘DBL_DECIMAL_DIG’ undeclared

[barracuda156]

/usr/bin/gcc-4.2 -std=gnu99 -DUNITSFILE=\"/opt/local/share/units/definitions.units\" -DLOCALEMAP=\"/opt/local/share/units/locale_map.txt\" -DREADLINE -DNO_SUPPRESS_APPEND -DHAVE_IOCTL -DSUPPORT_UTF8 -DPACKAGE_NAME=\"GNU\ units\" -DPACKAGE_TARNAME=\"units\" -DPACKAGE_VERSION=\"2.24\" -DPACKAGE_STRING=\"GNU\ units\ 2.24\" -DPACKAGE_BUGREPORT=\"adrianm@gnu.org\" -DPACKAGE_URL=\"https://www.gnu.org/software/units/\" -DHAVE_STDIO_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_STRINGS_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_UNISTD_H=1 -DSTDC_HEADERS=1 -I/opt/local/include -I/opt/local/include -pipe -Os -arch ppc -fpic -I. -c getopt.c
/usr/bin/gcc-4.2 -std=gnu99 -DUNITSFILE=\"/opt/local/share/units/definitions.units\" -DLOCALEMAP=\"/opt/local/share/units/locale_map.txt\" -DREADLINE -DNO_SUPPRESS_APPEND -DHAVE_IOCTL -DSUPPORT_UTF8 -DPACKAGE_NAME=\"GNU\ units\" -DPACKAGE_TARNAME=\"units\" -DPACKAGE_VERSION=\"2.24\" -DPACKAGE_STRING=\"GNU\ units\ 2.24\" -DPACKAGE_BUGREPORT=\"adrianm@gnu.org\" -DPACKAGE_URL=\"https://www.gnu.org/software/units/\" -DHAVE_STDIO_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_STRINGS_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_UNISTD_H=1 -DSTDC_HEADERS=1 -I/opt/local/include -I/opt/local/include -pipe -Os -arch ppc -fpic -I. -c getopt1.c
sed s!@DATAFILE@!/opt/local/share/units/definitions.units! ./units.man > units.1
sed -e "s*output_dir = ''*output_dir='/opt/local/var/lib/units/'*"\
            -e "s@/usr/bin/python@/opt/local/bin/python3.13@" \
             ./units_cur > units_cur_inst
units.c: In function ‘definevariable’:
units.c:5527: error: ‘DBL_DECIMAL_DIG’ undeclared (first use in this function)
units.c:5527: error: (Each undeclared identifier is reported only once
units.c:5527: error: for each function it appears in.)
make: *** [units.o] Error 1
make: *** Waiting for unfinished jobs....

[barracuda156]

It is C11: ​https://cppreference.com/w/c/types/limits.html

[saj (Saj Goonatilleke)]

Hello. Broken on what?

​https://ports.macports.org/port/gunits/details/

Looks like it is broken on OS X 10.7 through 10.11. (Though, oddly, not 10.5 or 10.6. It looks like MacPorts builds with a newer compiler on these platforms?)

Is there a way to ask buildbot to build for these old releases prior to merge? I am unable to test on anything older than 12 so it is hard to get feedback.

DEBUG: Xcode 8.2.1, CLT 8.2.0.0.1.1480973914

​list of clangs in old Xcode releases

clang 8?

​https://build.macports.org/builders/ports-10.11_x86_64-builder/builds/293844/steps/install-port/logs/stdio

checking for /usr/bin/clang option to enable C11 features... none needed

​https://releases.llvm.org/8.0.0/tools/clang/docs/UsersManual.html

If no -std option is specified, clang defaults to gnu11 mode.

I don't think I can fix this without access to an old machine. Don't know what is going on.

Tempted to pin these old OS X releases to gunits 2.22 as a quick fix.

[ryandesign (Ryan Carsten Schmidt)]

Replying to saj:

​https://ports.macports.org/port/gunits/details/

Looks like it is broken on OS X 10.7 through 10.11. (Though, oddly, not 10.5 or 10.6.

We haven't had a 10.5 build machine in years so any status information you see about that OS version on ports.macports.org is outdated.

It looks like MacPorts builds with a newer compiler on these platforms?)

The clang on 10.6 is so old as to be useless so MacPorts does use a newer MacPorts clang on 10.6, but what compiler MacPorts defaults to subject to change. Write your ports to work regardless what compiler MacPorts picks by default, meaning if a port is incompatible with a particular compiler, express that using compiler.blacklist so that MacPorts will pick something else.

However in this case there isn't necessarily a compiler incompatibility, just a missing compiler flag which can be added easily.

Is there a way to ask buildbot to build for these old releases prior to merge?

Buildbot only does thing after a commit occurs on master.

The CI system you access via pull requests runs on GitHub Actions, not Buildbot. The runners available to us with GitHub Actions are limited to OS versions supported by Apple.

DEBUG: Xcode 8.2.1, CLT 8.2.0.0.1.1480973914

​list of clangs in old Xcode releases

No need to consult a third-party document; we maintain such a list at XcodeVersionInfo.

clang 8?

Apple clang 8. Apple clang version numbers follow Xcode version numbers. Apple clang version numbers are different from llvm.org version numbers.

​https://build.macports.org/builders/ports-10.11_x86_64-builder/builds/293844/steps/install-port/logs/stdio

checking for /usr/bin/clang option to enable C11 features... none needed

​https://releases.llvm.org/8.0.0/tools/clang/docs/UsersManual.html

That's llvm.org clang 8, not Apple clang 8.

A table matching Apple clang versions to llvm.org clang versions is at ​https://en.wikipedia.org/wiki/Xcode#Toolchain_versions where you see Apple clang 8.x is based on (but not identical to) llvm.org clang 3.9.

[ryandesign (Ryan Carsten Schmidt)]

Since this software is using C11 features, the portfile must use compiler.c_standard 2011. This ensures MacPorts picks a compiler that supports that standard, though not necessarily one that defaults to that standard; therefore, using the right -std flag is still essential. The build system should do this; if it doesn't, the portfile can do it.

[saj (Saj Goonatilleke)]

Thank you.

After some faffing about, I installed 10.8 in a virtual machine, and tested there.

It would seem that compiler.c_standard 2011 is not enough.

​float.h is missing mandatory C11 fp macros like DBL_DECIMAL_DIG and LDBL_DECIMAL_DIG [github.com/llvm]

This issue was fixed [...] in Clang 3.9

Xcode clang, on 10.8, appears to satisfy compiler.c_standard 2011 -- for it is selected for use by MacPorts -- however the C11 implementation in this old compiler is incomplete.

I sent a patch here.
​https://github.com/macports/macports-ports/pull/28690

[saj (Saj Goonatilleke)]

In cc8fb97363f960937086dc61ad1e04c050a01fc4/macports-ports (master):

gunits: fix builds on legacy platforms

4051db1e8ec regressed on OS X 10.7 through 10.11. (Sorry.)
gunits 2.24 requires C11 floating point macros.
Old clangs did not fully implement these macros.

Closes: #72595

[saj (Saj Goonatilleke)]

Builds now succeed on 10.6 through 10.10. Unfortunately, the build is still broken on 10.11. I will reopen.

llvm.org say they fixed this in llvmorg-3.9.0. I wanted to know which Apple clang incorporated that upstream release.

XcodeVersionInfo#OSX10.11

AFAICS, there are no llvm.org version identifiers here. In my earlier patch, I had resorted to the information on Wikipedia.

​https://en.wikipedia.org/wiki/Xcode#Xcode_7.0_-_10.x_(since_Free_On-Device_Development)_2

The row for Xcode 8.0, with Apple clang-800.0.38, looked like the minimum: LLVM 3.9.0svn. And so I wrote this:

compiler.blacklist-append   {clang < 800}

The buildbot for 10.11 logged the following.

DEBUG: Xcode 8.2.1, CLT 8.2.0.0.1.1480973914
DEBUG: SDK 10.11

DEBUG: compiler clang 800.0.42.1 not blacklisted because it doesn't match {clang < 800}

I can only guess the underlying llvm clang in Xcode is still too old.
i.e. 800 should be substituted with some other, greater, number.

​https://stackoverflow.com/a/32997109

The LLVM version reported was always misleading. "3.6.0svn" means that code was branched some time after 3.5 and before 3.6.

This is nuts.

I am afraid I don't have time to set up another test environment on 10.11, and I cannot send a PR in good faith without testing it on 10.11 first. If you are on 10.11, and if this bothers you, please try bumping that number.

[ryandesign (Ryan Carsten Schmidt)]

Replying to saj:

Xcode clang, on 10.8, appears to satisfy compiler.c_standard 2011 -- for it is selected for use by MacPorts -- however the C11 implementation in this old compiler is incomplete.

This is indeed a general problem with trying to select a compiler that satisfies a language standard. MacPorts currently uses the rules documented in CompilerSelection. For example, we consider Xcode 5's clang to have C11 support. However, some parts of C11 are missing in that version, as you discovered. For example, support for stdatomic wasn't added until Xcode 7's clang so we have had to blacklist {clang < 700} in many ports. We could increase the minimum Xcode/clang version that MacPorts considers as supporting C11, at the expense of many more ports needing to use MacPorts compilers on older systems even when those ports worked just fine with the older Xcode clang. Imposing stricter compiler requirements can also have the unintended consequence of introducing dependency cycles, which will prevent everything in that dependency cycle and anything that depends on it from building. I'm not sure whether it's best to modify the base compiler selection logic or leave it alone and tweak individual ports as they're found.

[ryandesign (Ryan Carsten Schmidt)]

In d7c451a6ebcb7fc66f7031f98310211d725498bd/macports-ports (master):

gunits: Try blacklisting clang < 802

See: #72595

[saj (Saj Goonatilleke)]

Replying to ryandesign:

I'm not sure whether it's best to modify the base compiler selection logic or leave it alone and tweak individual ports as they're found.

I think the approach you have now is fine. There will always be standards compliance bugs. If MP redefined the meaning of compiler.c_standard 2011 to Really Truly C11 with all known compliance bugs fixed, then we might unnecessarily pull in clang-20 (or whatever). Maybe there is still some oddball bug that is yet to be discovered.

at the expense of many more ports needing to use MacPorts compilers on older systems even when those ports worked just fine with the older Xcode clang

Yes. I have no qualms with CompilerSelection.

The project's view towards legacy systems is what puts casual contributors in a bit of an awkward predicament.

​https://lists.macports.org/pipermail/macports-dev/2025-January/046014.html

10.4 is of course already unsupported in the sense that we have no expectation that maintainers should fix any problems on OS versions older than current-2.

If, as in this case, I send a trivial update to a port, and if that update happens to break someone on Lion, should I feel bad? Official policy says don't worry about it, but this bug report might suggest otherwise. I did actually feel bad, and tried to fix it when I had time this weekend, but it is very hard to cross build against all of these legacy platforms myself. Maybe it would be better for people like me to not send patches to MacPorts. I don't know what I might break.

I happen to think it is great that you extend best effort support to legacy systems. Earlier in this bug, I noted I had installed 10.8 in order to test a patch. This was an interesting experience. I was surprised by how many ports still worked on 10.8. (The experience also motivated me to fix this port.) Granted, I could not browse the web, and ultimately had to funnel all the data over nc from a machine with a contemporary TLS stack, but, once finally installed, MacPorts did work. ;)

I suppose what I'm trying to say is that I don't see this as a CompilerSelection issue but more of a testing issue.

GitHub Actions was primarily designed for use by the sorts of developers who would find it unthinkable for anyone on the planet to be running anything older than Sequoia. (I was surprised to see they still support Ventura.)

MP already has great build infrastructure in the form of your own buildbot. There is a full cross build here, all the way down to 10.6. Would it be possible to allow contributors to submit patches to buildbot for cross build prior to trunk merge? I think that test feedback would have helped in this case. I am unsure whether other casual contributors would also value this test feedback, or whether it is worth the trouble given most ports commits come from people who know what they are doing. (Archives from such test builds should not be served from mirrors, obviously. I expect build capacity is very limited. Instead of automatically building for all PRs, as GHA does with their bottomless compute, maybe the buildbot submissions should be manual -- and deprioritised below trunk builds.)

anyhoo

I note your review feedback regarding the bump to revision. Thanks. Also thanks for your last commit, and for all your help!