max_align_t from libgnu/stddef.h conflicts with gcc 5.3.1

[Peter Simons]

Hi,

I'm using the current "master" of gnulib at v0.1-744-gf0be2ae to build a
C project on Linux/x86_64. This works fine with older compilers, but gcc
5.3.1 cannot build my project because of the following error:

gcc -DHAVE_CONFIG_H -I. -I..   -DDEBUG  -g -O2 -MT unistd.o -MD -MP -MF 
.deps/unistd.Tpo -c -o unistd.o unistd.c
In file included from unistd.h:56:0,
 from unistd.c:3:
./stddef.h:104:3: error: conflicting types for 'max_align_t'
 } max_align_t;
   ^
In file included from ./stddef.h:55:0,
 from unistd.h:56,
 from unistd.c:3:
/usr/lib64/gcc/x86_64-suse-linux/5/include/stddef.h:429:3: note: previous 
declaration of 'max_align_t' was here
 } max_align_t;
   ^
Makefile:647: recipe for target 'unistd.o' failed

Apparently, the stddef.h file provided by gnulib defines that type
differently than gcc 5.x does? Is that a known issue? Or am I using
gnulib wrong somehow?

Best regards,
Peter

Re: max_align_t from libgnu/stddef.h conflicts with gcc 5.3.1

[Paul Eggert]

I'm not observing the problem on Fedora 23 with gcc (GCC) 5.3.1 20151207 (Red 
Hat 5.3.1-2).


Can you reproduce the problem this way?

./gnulib-tool --dir foo --create-testdir unistd
cd foo
./configure
make
make check

As I understand it, GCC 5.3.1 should not need a substitute stddef.h. So if your 
system is creating one, you need to figure out why ./configure decided that 
stddef.h wasn't working. Look in config.log; it should say something like this:


configure:7608: checking for max_align_t
[ a lot of chatter ]
configure:7608: result: yes

Re: max_align_t from libgnu/stddef.h conflicts with gcc 5.3.1

[Peter Simons]

Hi Paul,

 > Can you reproduce the problem this way?
 >
 > ./gnulib-tool --dir foo --create-testdir unistd
 > cd foo
 > ./configure
 > make
 > make check

No, that sequence of commands gives no error. The check phase reports 12
out of 12 successful tests. The relevant bit from config.log is
available at .


 > As I understand it, GCC 5.3.1 should not need a substitute stddef.h.
 > So if your system is creating one, you need to figure out why
 > ./configure decided that stddef.h wasn't working.

Hmm. I'm observing that issue on two different Linux/x86_64 systems:
both openSUSE Tumbleweed and NixOS show the same error.


 > Look in config.log; it should say something like this:
 >
 > configure:7608: checking for max_align_t
 > [ a lot of chatter ]
 > configure:7608: result: yes

The relevant bit is at .

Apparently, the second (failing) build decides that max_align_t is not
available, but the gnulib-generate test build thinks it is. Not sure how
to explain that.

For what it's worth, the full source code of my project is available at
http://git.savannah.gnu.org/cgit/mini-httpd.git.

Best regards,
Peter

Re: max_align_t from libgnu/stddef.h conflicts with gcc 5.3.1

[Ángel González]

On 01/04/16 11:30, Peter Simons wrote:

Apparently, the second (failing) build decides that max_align_t is not
available, but the gnulib-generate test build thinks it is. Not sure how
to explain that.

For what it's worth, the full source code of my project is available at
http://git.savannah.gnu.org/cgit/mini-httpd.git.

Best regards,
Peter


The problem is «gcc vs g++»

gnulib is running the test against g++, and it doesn't define max_align_t,
so it is right in that a replacement is needed there.

The compilation error is on libgnu/unistd.c, a C program compiled by gcc.
gcc doesn't need the replacement header (provides max_align_t itself), and
thus the double-definition appears.

I'm not sure _how_ is this supposed to be configured. mini-httpd is a 
C++ project, it's
gnulib the one introducing a dummy unistd.c file. Maybe using .cpp 
extensions on the

libraries would be appropiate.

For this specific issue, another solution would be to add a #ifndef 
_GCC_MAX_ALIGN_T

guard to the replacement unistd.h.
Although the latter doesn't fix the underlying problem.


Best regards

Re: max_align_t from libgnu/stddef.h conflicts with gcc 5.3.1

[Paul Eggert]

Ángel González wrote:

For this specific issue, another solution would be to add a #ifndef
_GCC_MAX_ALIGN_T
guard to the replacement unistd.h.
Although the latter doesn't fix the underlying problem.


That may be the best we can do on short notice, so I did that by installing the 
attached. Thanks for the diagnosis.
From caf0ca071d641550d9b51cf93ae9222a74b6cf2d Mon Sep 17 00:00:00 2001
From: Paul Eggert 
Date: Fri, 1 Apr 2016 21:01:17 -0700
Subject: [PATCH] stddef: support configuring with g++
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Problem reported by Ángel González in:
http://lists.gnu.org/archive/html/bug-gnulib/2016-04/msg3.html
* lib/stddef.in.h (_GL_STDDEF_ALIGNAS, max_align_t):
Do not define if _GCC_MAX_ALIGN_T is defined.
---
 ChangeLog   | 8 
 lib/stddef.in.h | 6 --
 2 files changed, 12 insertions(+), 2 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index ca6c36b..ef7629f 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,11 @@
+2016-04-01  Paul Eggert  
+
+   stddef: support configuring with g++
+   Problem reported by Ángel González in:
+   http://lists.gnu.org/archive/html/bug-gnulib/2016-04/msg3.html
+   * lib/stddef.in.h (_GL_STDDEF_ALIGNAS, max_align_t):
+   Do not define if _GCC_MAX_ALIGN_T is defined.
+
 2016-03-25  Paul Eggert  
 
test-framework-sh: minor cleanups
diff --git a/lib/stddef.in.h b/lib/stddef.in.h
index 2beb7f5..0e75b9c 100644
--- a/lib/stddef.in.h
+++ b/lib/stddef.in.h
@@ -81,8 +81,10 @@
 # define wchar_t int
 #endif
 
-/* Some platforms lack max_align_t.  */
-#if !@HAVE_MAX_ALIGN_T@
+/* Some platforms lack max_align_t.  The check for _GCC_MAX_ALIGN_T is
+   a hack in case the configure-time test was done with g++ even though
+   we are currently compiling with gcc.  */
+#if ! (@HAVE_MAX_ALIGN_T@ || defined _GCC_MAX_ALIGN_T)
 /* On the x86, the maximum storage alignment of double, long, etc. is 4,
but GCC's C11 ABI for x86 says that max_align_t has an alignment of 8,
and the C11 standard allows this.  Work around this problem by
-- 
2.5.5