mod_gnutls: error: use of unknown builtin '__builtin_add_overflow'

[ryandesign (Ryan Carsten Schmidt)]

​mod_gnutls doesn't build on 10.7 thru 10.10 inclusive:

gnutls_sni.c:48:9: warning: implicit declaration of function 'bswap_16' is invalid in C99 [-Wimplicit-function-declaration]
    u = bswap_16(u);
        ^
gnutls_io.c:624:16: error: use of unknown builtin '__builtin_add_overflow' [-Wimplicit-function-declaration]
            && __builtin_add_overflow(readbytes, 0, &len))
               ^
gnutls_ocsp.c:476:9: error: use of unknown builtin '__builtin_add_overflow' [-Wimplicit-function-declaration]
    if (__builtin_add_overflow(fplen, 0, &fingerprint.size))
        ^
1 error generated.
make[1]: *** [mod_gnutls_la-gnutls_io.lo] Error 1

It ​does build on 10.6 using clang 9 so adding compiler.blacklist-append {clang < 800} could be one solution. However if the code can be fixed to work with old compilers that would be preferable.

[Schamschula (Marius Schamschula)]

The sqlite folks have run into the same issue. Their workaround actually goes in the other direction, i.e. don't blacklist any clang version: ​https://www.sqlite.org/src/info/8d3f485d86b2f2d8

[ryandesign (Ryan Carsten Schmidt)]

Well. sqlite appears to have been using the clang version to decide which features are available, which is terrible; they should have been using __has_feature or something. And they were using open source clang numbers, not understanding that Apple has a different clang version numbering scheme.

If mod_gnutls is doing the same thing in their code, then indeed they should fix their code too. I don't think that's what they're doing though. Looking at their code briefly, they seem to assume that all clangs support __builtin_add_overflow, which evidently they don't.

[Schamschula (Marius Schamschula)]

I haven't had time to check. I've been slightly distracted trying to get some of my standard tools to work on some central CA coast OS...

[Schamschula (Marius Schamschula)]

It looks like blacklisting compilers is the only option.

[ryandesign (Ryan Carsten Schmidt)]

What does that mean? You reported the issue to them and they refuse to fix it? I don't see an issue filed about this in their issue tracker.

[Schamschula (Marius Schamschula)]

No. That was based on the commit and comments ​https://github.com/macports/macports-ports/commit/018c4fb684733ea47d8ce71ed8a7a85bc103185e#commitcomment-40227141 and ​https://github.com/macports/macports-ports/commit/8a0a94aa447e917d3b2bec0cc33cebd87792a7b8, ​https://github.com/macports/macports-ports/commit/316b25605910ad25fe023e74dd35d36100cf63dd, and ​https://github.com/macports/macports-ports/commit/cd4ac232782cefc89ca18e951f683f4ae98d4836, leading up to it.

Similar to the comments I received on an unrelated recent ticket for libgpg-error, I suspect that most upstream developers are not likely to want to add code for 'obsolete' macOS versions. Hence, my approach was to find a work-around on our end.

I hesitate submitting bug reports that I can't locally reproduce. Unfortunately, I don't have the time and space to set up old machines (which I do have in storage) to test everything on older macOS versions.

I'm set up to build on current, current - 1 or current + 1 (often incomplete, as the build tools often are broken), depending on the time of year..

I greatly appreciate the help from Sergey Federov, Kencu and Renee Otten who apparently do have these resources, and often submit PRs to fix these legacy OS builds of my ports.