gnutls fails to build on ML buildbot (and probably others) due to missing stdnoreturn.h

[neverpanic (Clemens Lang)]

Hi,

The

• SL: ​https://build.macports.org/builders/buildports-snowleopard-x86_64/builds/28908
• Lion: ​https://build.macports.org/builders/buildports-lion-x86_64/builds/22682, and
• ML: ​https://build.macports.org/builders/buildports-mtln-x86_64/builds/16727

buildbots failed to build GnuTLS 3.3.7. The problem seems to be a missing stdnoreturn.h header file in src/libopts/autoopts.h:

Making all in libopts
make[4]: Entering directory `/opt/local/var/macports/build/_opt_mports_dports_devel_gnutls/gnutls/work/gnutls-3.3.7/src/libopts'
/bin/sh ../../libtool  --tag=CC   --mode=compile /usr/bin/clang -DHAVE_CONFIG_H -I. -I../..  -I../.. -I/opt/local/include  -pipe -Os -arch x86_64 -MT libopts_la-libopts.lo -MD -MP -MF .deps/libopts_la-libopts.Tpo -c -o libopts_la-libopts.lo `test -f 'libopts.c' || echo './'`libopts.c
libtool: compile:  /usr/bin/clang -DHAVE_CONFIG_H -I. -I../.. -I../.. -I/opt/local/include -pipe -Os -arch x86_64 -MT libopts_la-libopts.lo -MD -MP -MF .deps/libopts_la-libopts.Tpo -c libopts.c  -fno-common -DPIC -o .libs/libopts_la-libopts.o
In file included from libopts.c:12:
./autoopts.h:35:10: fatal error: 'stdnoreturn.h' file not found
#include <stdnoreturn.h>
         ^
1 error generated.
make[4]: *** [libopts_la-libopts.lo] Error 1

The file seems to be part of libopts, the problem seems to have been introduced in version 3.3.7. stdnoreturn.h is part of the next C standard, and seems to be unavailable on older systems. Upstream commit that added the change was

commit 3d1a66d4f2716c72b146c6ec1feb2d886e2ef3b3
Author: Nikos Mavrogiannopoulos <nmav@gnutls.org>
Date:   Tue Jul 29 22:21:36 2014 +0200

    updated to libopts 5.18.3

I don't see why the new header was necessary, so the proper fix is probably removing it completely.

Please advise upstream about this problem by filing a bug report in their bug tracker.

[mkae (Marko Käning)]

This doesn't happen on Mavericks.

[mkae (Marko Käning)]

Cc Me!

[bK4gYuRo]

It does happen on Lion:

:info:build make[4]: Entering directory `/opt/local/var/macports/build/_opt_local_var_mac
ports_sources_rsync.macports.org_release_tarballs_ports_devel_gnutls/gnutls/work/gnutls-3
.3.7/src/libopts'
:info:build /bin/sh ../../libtool  --tag=CC   --mode=compile /usr/bin/llvm-gcc-4.2 -DHAVE
_CONFIG_H -I. -I../..  -I../.. -I/opt/local/include  -pipe -Os -arch x86_64 -MT libopts_l
a-libopts.lo -MD -MP -MF .deps/libopts_la-libopts.Tpo -c -o libopts_la-libopts.lo `test -
f 'libopts.c' || echo './'`libopts.c
:info:build libtool: compile:  /usr/bin/llvm-gcc-4.2 -DHAVE_CONFIG_H -I. -I../.. -I../.. 
-I/opt/local/include -pipe -Os -arch x86_64 -MT libopts_la-libopts.lo -MD -MP -MF .deps/l
ibopts_la-libopts.Tpo -c libopts.c  -fno-common -DPIC -o .libs/libopts_la-libopts.o
:info:build In file included from libopts.c:12:
:info:build autoopts.h:35:25: error: stdnoreturn.h: No such file or directory

[bK4gYuRo]

Cc Me!

[neverpanic (Clemens Lang)]

Looking into the code a little more, it seems noreturn is actually being used now. I'm not sure how to proceed in this case, either upstream should decide that a C11-compatible compiler is necessary or do something about it, like including a compatibility header (it seems gnulib has one).

[Schamschula (Marius Schamschula)]

I have posted this information to the gnutls-devel mailing list.

[udbraumann]

Cc Me!

[zzanderr]

I just attempted to upgrade gnutls and ran into the same error during the build phase (G4 PowerBook running OS X 10.5). After reading Cal's last post, I checked to see if there was a "stdnoreturn.h" somewhere under "/opt" and found one:

          /opt/lib/gcc48/gcc/ppc-apple-darwin9/4.8.3/include/stdnoreturn.h

I cleaned up the failed build and used

          port upgrade gnutls configure.compiler=macports-gcc-4.8

finishing the upgrade with no errors. So thanks for the info, Cal. However, if anyone knows of a reason why I shouldn't use gcc48 for gnutls (on a PowerBook), please let me know.

[Schamschula (Marius Schamschula)]

On my systems, I only found this issue under Lion (10.7.5). Both Mountain Lion and Mavericks built cleanly.

[orbeckst (Oliver Beckstein)]

Cc Me!

[Schamschula (Marius Schamschula)]

I managed to build gnutls 3.3.7 under Lion, using the following command:

sudo port install gnutls configure.compiler=macports-clang-3.4

Thus, it seems that, perhaps, we need to blacklist the older Apple compilers.

[udbraumann]

Replying to mschamschula@…:

I managed to build gnutls 3.3.7 under Lion, using the following command:

sudo port install gnutls configure.compiler=macports-clang-3.4

This also works on SL 10.6.8, however

sudo port install gnutls configure.compiler=macports-gcc-4.8

works as well, and my guess is that earlier versions of macports' clang or gcc also work.

Thus, it seems that, perhaps, we need to blacklist the older Apple compilers.

This would require some care, in particular when defining alternative compilers. macports-gcc-4.* does not allow for universal builds, and sadly clang-3.* is not working for PPC. I would prefer if some work-around referring to a compatibility header as was outlined above ​https://trac.macports.org/ticket/44755?replyto=12#comment:5 could be used. It would be sad to end up like for the boost port which presently can only be build using some manual hacks on PPC platforms, e.g. ​https://trac.macports.org/ticket/39809#comment:39 And yes, I am aware that PPC is no longer officially supported. However, if clang would work on PPC, those C11 issues easily could be worked around.

[Schamschula (Marius Schamschula)]

I got a patch file from the GnuTLS maintainer.

The new revision has successfully built on Lion, ML and Mavericks.

Patches attached.

[neverpanic (Clemens Lang)]

Applied in r124556 without the revision bump, because the port either built correctly or not at all, in which case we don't have to force rebuilds.

Can you file the bug upstream with autogen so it gets fixed where it originated?