Discussion:
max_align_t fails with clang 6.1 on OS X 10.10
(too old to reply)
Werner LEMBERG
2017-08-28 06:43:18 UTC
Permalink
Raw Message
Building ttfautohint (http://repo.or.cz/ttfautohint.git/) on OS X
10.10 (XCode 6.4) fails. The data below is taken from a travis build
(https://travis-ci.org/source-foundry/ttfautohint-build/jobs/269031319#L3401).

Here's the list of the gnulib modules I use in ttfautohint:

dirname
fcntl-h
getopt-gnu
git-version-gen
isatty
memmem-simple
progname
stdarg
stdbool
stdint
strerror_r-posix
strndup
strtok_r
strtoull
vasprintf


Werner


======================================================================

...
checking for max_align_t... no
...

In file included from ../gnulib/src/stdio.h:53:
../gnulib/src/stddef.h:106:3: In file included from main.cpp:error26: :
In file included from ../gnulib/src/stdio.htypedef redefinition with different types ('union max_align_t' vs 'long double'):53
:
../gnulib/src/stddef.h:106:3: error: typedef redefinition with different types ('union max_align_t' vs 'long double')
} max_align_t;
^
} max_align_t;
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/clang/6.1.0/include/stddef.h ^:
119:21: note: previous definition is here
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/clang/6.1.0/include/stddef.h:119:21: note: previous definition is here
typedef long double max_align_t;
^
typedef long double max_align_t;
^
1 error generated.

[there are obviously two output streams intermingled in the log file;
I haven't cleaned up the messages]

Note that ttfautohint can be compiled fine with OS X 10.11 and newer;
it also succeeds on OS X 10.5.8 (which still uses gcc by default).


Werner
Paul Eggert
2017-08-28 08:20:23 UTC
Permalink
Raw Message
Post by Werner LEMBERG
checking for max_align_t... no
Why did this say "no" even though stddef.h evidently defines max_align_t? Please
look for details in config.log.
Werner LEMBERG
2017-08-29 19:52:29 UTC
Permalink
Raw Message
Post by Paul Eggert
Post by Werner LEMBERG
checking for max_align_t... no
Why did this say "no" even though stddef.h evidently defines
max_align_t? Please look for details in config.log.
Below. For reference you can also find the complete `config.log' file
attached.


Werner


======================================================================

...
uname -v = Darwin Kernel Version 14.5.0: Thu Apr 21 20:40:54 PDT 2016; root:xnu-2782.50.3~1/RELEASE_X86_64
...
configure:4590: gcc --version >&5
Apple LLVM version 6.1.0 (clang-602.0.53) (based on LLVM 3.6.0svn)
Target: x86_64-apple-darwin14.5.0
...
configure:17517: checking for max_align_t
configure:17517: gcc -c -I/Users/travis/ttfautohint-build/local/include -g -O2 conftest.c >&5
conftest.c:145:13: error: use of undeclared identifier 'max_align_t'
if (sizeof (max_align_t))
^
1 error generated.
configure:17517: $? = 1
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME "ttfautohint"
| #define PACKAGE_TARNAME "ttfautohint"
| #define PACKAGE_VERSION "1.7"
| #define PACKAGE_STRING "ttfautohint 1.7"
| #define PACKAGE_BUGREPORT "freetype-***@nongnu.org"
| #define PACKAGE_URL ""
| #define PACKAGE "ttfautohint"
| #define VERSION "1.7"
| #define STDC_HEADERS 1
| #define HAVE_SYS_TYPES_H 1
| #define HAVE_SYS_STAT_H 1
| #define HAVE_STDLIB_H 1
| #define HAVE_STRING_H 1
| #define HAVE_MEMORY_H 1
| #define HAVE_STRINGS_H 1
| #define HAVE_INTTYPES_H 1
| #define HAVE_STDINT_H 1
| #define HAVE_UNISTD_H 1
| #define __EXTENSIONS__ 1
| #define _ALL_SOURCE 1
| #define _DARWIN_C_SOURCE 1
| #define _GNU_SOURCE 1
| #define _POSIX_PTHREAD_SEMANTICS 1
| #define __STDC_WANT_IEC_60559_ATTRIBS_EXT__ 1
| #define __STDC_WANT_IEC_60559_BFP_EXT__ 1
| #define __STDC_WANT_IEC_60559_DFP_EXT__ 1
| #define __STDC_WANT_IEC_60559_FUNCS_EXT__ 1
| #define __STDC_WANT_IEC_60559_TYPES_EXT__ 1
| #define __STDC_WANT_LIB_EXT2__ 1
| #define __STDC_WANT_MATH_SPEC_FUNCS__ 1
| #define _TANDEM_SOURCE 1
| #define HAVE_CXX11 1
| #define HAVE_ALLOCA_H 1
| #define HAVE_ALLOCA 1
| #define HAVE_DECL_STRERROR_R 1
| #define HAVE_STRERROR_R 1
| #define HAVE_UNISTD_H 1
| #define HAVE_GETOPT_H 1
| #define HAVE_SYS_CDEFS_H 1
| #define HAVE_LIMITS_H 1
| #define HAVE_SYS_MMAN_H 1
| #define HAVE_WCHAR_H 1
| #define HAVE_STDINT_H 1
| #define HAVE_SYS_SOCKET_H 1
| #define HAVE_SYMLINK 1
| #define HAVE_GETPROGNAME 1
| #define HAVE_MPROTECT 1
| #define HAVE_STRERROR_R 1
| #define HAVE_CATGETS 1
| #define HAVE_SNPRINTF 1
| #define HAVE_STRNDUP 1
| #define HAVE_WORKING_O_NOATIME 0
| #define HAVE_WORKING_O_NOFOLLOW 1
| #define HAVE_GETOPT_H 1
| #define HAVE_GETOPT_LONG_ONLY 1
| #define USE_POSIX_THREADS 1
| #define MAP_ANONYMOUS MAP_ANON
| #define HAVE_MAP_ANONYMOUS 1
| #define HAVE_DECL_MEMMEM 1
| #define HAVE__BOOL 1
| #define HAVE_WCHAR_T 1
| #define HAVE_WINT_T 1
| #define HAVE_UNSIGNED_LONG_LONG_INT 1
| #define HAVE_LONG_LONG_INT 1
| #define BITSIZEOF_PTRDIFF_T 64
| #define BITSIZEOF_SIZE_T 64
| #define BITSIZEOF_SIG_ATOMIC_T 32
| #define BITSIZEOF_WCHAR_T 32
| #define BITSIZEOF_WINT_T 32
| #define HAVE_SIGNED_SIG_ATOMIC_T 1
| #define HAVE_SIGNED_WCHAR_T 1
| #define HAVE_SIGNED_WINT_T 1
| #define PTRDIFF_T_SUFFIX l
| #define SIZE_T_SUFFIX ul
| #define SIG_ATOMIC_T_SUFFIX
| #define WCHAR_T_SUFFIX
| #define WINT_T_SUFFIX
| #define REPLACE_STRERROR_0 1
| #define HAVE_DECL_STRERROR_R 1
| #define restrict __restrict
| #define HAVE_RAW_DECL_FFSL 1
| #define HAVE_RAW_DECL_FFSLL 1
| #define HAVE_RAW_DECL_MEMMEM 1
| #define HAVE_RAW_DECL_STPCPY 1
| #define HAVE_RAW_DECL_STPNCPY 1
| #define HAVE_RAW_DECL_STRDUP 1
| #define HAVE_RAW_DECL_STRNCAT 1
| #define HAVE_RAW_DECL_STRNDUP 1
| #define HAVE_RAW_DECL_STRNLEN 1
| #define HAVE_RAW_DECL_STRPBRK 1
| #define HAVE_RAW_DECL_STRSEP 1
| #define HAVE_RAW_DECL_STRCASESTR 1
| #define HAVE_RAW_DECL_STRTOK_R 1
| #define HAVE_RAW_DECL_STRERROR_R 1
| #define HAVE_RAW_DECL_STRSIGNAL 1
| #define HAVE_DECL_STRNDUP 1
| #define HAVE_DECL_STRNLEN 1
| #define HAVE_DECL_STRTOK_R 1
| #define _USE_STD_STAT 1
| #define HAVE_INTTYPES_H_WITH_UINTMAX 1
| #define HAVE_STDINT_H_WITH_UINTMAX 1
| #define HAVE_INTMAX_T 1
| #define DBL_EXPBIT0_WORD 1
| #define DBL_EXPBIT0_BIT 20
| #define HAVE_SNPRINTF 1
| #define HAVE_STRNLEN 1
| #define HAVE_WCSLEN 1
| #define HAVE_WCSNLEN 1
| #define HAVE_MBRTOWC 1
| #define HAVE_WCRTOMB 1
| #define HAVE_DECL__SNPRINTF 0
| #define HAVE_SNPRINTF_RETVAL_C99 1
| #define HAVE_ALLOCA 1
| #define HAVE___BUILTIN_EXPECT 1
| #define GNULIB_DIRNAME 1
| #define HAVE_RAW_DECL_FCNTL 1
| #define HAVE_RAW_DECL_OPENAT 1
| #define __GETOPT_PREFIX rpl_
| #define HAVE_DECL_PROGRAM_INVOCATION_NAME 0
| #define HAVE_DECL_PROGRAM_INVOCATION_SHORT_NAME 0
| #define HAVE_DECL___ARGV 0
| #define HAVE_VAR___PROGNAME 1
| #define GNULIB_TEST_ISATTY 1
| #define HAVE_PTHREAD_RWLOCK 1
| #define HAVE_PTHREAD_RWLOCK_RDLOCK_PREFER_WRITER 1
| #define HAVE_PTHREAD_MUTEX_RECURSIVE 1
| #define GNULIB_LOCK 1
| #define HAVE_MALLOC_POSIX 1
| #define GNULIB_TEST_MALLOC_POSIX 1
| #define GNULIB_TEST_MEMCHR 1
| #define HAVE_MEMMEM 1
| #define GNULIB_TEST_MEMMEM 1
| #define GNULIB_MSVC_NOTHROW 1
| #define HAVE_DECL_PROGRAM_INVOCATION_NAME 0
| #define HAVE_DECL_PROGRAM_INVOCATION_SHORT_NAME 0
| #define HAVE_STDINT_H 1
| /* end confdefs.h. */
| #include <stddef.h>
|
|
| int
| main ()
| {
| if (sizeof (max_align_t))
| return 0;
| ;
| return 0;
| }
configure:17517: result: no
Paul Eggert
2017-08-30 02:30:28 UTC
Permalink
Raw Message
Post by Werner LEMBERG
configure:17517: gcc -c -I/Users/travis/ttfautohint-build/local/include -g -O2 conftest.c >&5
conftest.c:145:13: error: use of undeclared identifier 'max_align_t'
Evidently the stddef.h found by the above command does not define max_align_t,
whereas the stddef.h found by the command 'CXX main.o' in
<https://travis-ci.org/source-foundry/ttfautohint-build/jobs/269031319#L3401>
does define max_align_t. Can you investigate why this is so? Perhaps CXX uses
different -I options, or perhaps stddef.h does not define max_align_t if C++.
Ideally 'configure' should be using the same compiler and options as 'make';
when that isn't true, there can be trouble.
Werner LEMBERG
2017-08-30 05:12:21 UTC
Permalink
Raw Message
Post by Paul Eggert
Post by Werner LEMBERG
configure:17517: gcc -c
-I/Users/travis/ttfautohint-build/local/include -g -O2 conftest.c >&5
conftest.c:145:13: error: use of undeclared identifier 'max_align_t'
Evidently the stddef.h found by the above command does not define
max_align_t, whereas the stddef.h found by the command 'CXX main.o'
in
<https://travis-ci.org/source-foundry/ttfautohint-build/jobs/269031319#L3401>
does define max_align_t. Can you investigate why this is so?
Perhaps CXX uses different -I options, or perhaps stddef.h does not
define max_align_t if C++.
I suspect that the used clang version doesn't activate C11 support by
default, while C++11 is available.

Right now I only have the `stddef.h' file of a later XCode version
(from 2015); however, looking at the copyright notice it seems that it
is unchanged. It contains the following.

#if (defined (__STDC_VERSION__) && __STDC_VERSION__ >= 201112L) \
|| (defined(__cplusplus) && __cplusplus >= 201103L)
typedef long double max_align_t;
#endif

Chris, do you have a chance to check

/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/6.1.0/include/stddef.h

of an OS X 10.10 Travis run whether the definition is identical?
Post by Paul Eggert
Ideally 'configure' should be using the same compiler and options as
'make'; when that isn't true, there can be trouble.
Sounds sensible. However, how to do that correctly? The
`max_align_t' test is part of gnulib, I don't ask for it. Shall I
simply add

AC_LANG_PUSH([C++])

right before the call to

gl_INIT

in my `configure.ac' file? Note that I also have

AX_CXX_COMPILE_STDCXX([11],,[optional])

to activate C++11 if available.


Werner
Paul Eggert
2017-08-30 06:20:06 UTC
Permalink
Raw Message
Post by Werner LEMBERG
Shall I
simply add
AC_LANG_PUSH([C++])
right before the call to
gl_INIT
in my `configure.ac' file?
Sorry, I don't use C++, so I'm not a good source of advice for it. That being
said, Libc-1158.50.2/include/stddef.h defines max_align_t if (__STDC_VERSION__
Post by Werner LEMBERG
= 201112L || __cplusplus >= 201103L). Could you try incorporating the
std-gnu11 module into your package, and see whether that fixes things? If so,
perhaps we could fix this problem for everybody by having stddef depend on
std-gnu11.
Werner LEMBERG
2017-09-03 00:13:30 UTC
Permalink
Raw Message
Could you try incorporating the std-gnu11 module into your package,
and see whether that fixes things? If so, perhaps we could fix this
problem for everybody by having stddef depend on std-gnu11.
This approach worked, cf.

https://travis-ci.org/source-foundry/ttfautohint-build/builds/271181245


Werner
Bruno Haible
2017-09-03 10:01:07 UTC
Permalink
Raw Message
Post by Werner LEMBERG
Could you try incorporating the std-gnu11 module into your package,
and see whether that fixes things? If so, perhaps we could fix this
problem for everybody by having stddef depend on std-gnu11.
This approach worked
Nevertheless, I don't agree that this is the solution.

What you are trying to do is to run the configure tests with a C compiler
and then use the resulting config.h with C code [1] and C++ code [2].

[1] http://repo.or.cz/ttfautohint.git/tree/HEAD:/lib
[2] http://repo.or.cz/ttfautohint.git/tree/HEAD:/frontend

This is not supported by Autoconf, and this is not supported by Gnulib -
simply because _any_ test result (not just the one for max_align_t) may
be different in C++ than it is in C.

There is one real fix for this problem: You create separate configure.ac
files for the lib/ and for the frontend directory, and each of them uses
a separate gnulib-tool invocation. (So, you must use the options --lib
and --source-base of gnulib-tool, to make sure the two gnulib-tool results
don't interfere.) The configure.ac for frontend/ must use AC_LANG_PUSH([C++])
before gl_INIT.

This fix is future-proof: It will work even after
- you request additional gnulib modules,
- the C standard features change,
- the C++ standard features change.

The other approaches are brittle: If we/you change something regarding
the max_align_t problem, you will continue to see issues
- on other platforms,
- when you request additional gnulib modules,
- when the C standard features change,
- when the C++ standard features change.

Among these other approaches are the following:

* You could add gnulib module 'std-gnu11' to the list of gnulib modules
you request. This has the chance of fixing other problems than the
max_align_t one, because C++ is closer to C11 than it is to C99.
But still, newer C or C++ standard can bring new problems.

* Gnulib could add a dependency from 'stddef' to 'std-gnu11'. I reject
this idea because this is a big change that affects all users, for a
situation that is not supported.

* Gnulib could test something like
HAVE_MAX_ALIGN_T || (defined(__APPLE__) && defined(__MACH__) && defined(__cplusplus))
instead of
HAVE_MAX_ALIGN_T
This is not such a big change, but it is brittle code, may only fix
the max_align_t problem, and is for a situation that is not supported.

In summary, I don't think Gnulib should change here, and you still the choice
among a real fix and a quick-fix.

Bruno
Werner LEMBERG
2017-09-03 12:01:36 UTC
Permalink
Raw Message
Post by Werner LEMBERG
Could you try incorporating the std-gnu11 module into your
package, and see whether that fixes things? If so, perhaps we
could fix this problem for everybody by having stddef depend on
std-gnu11.
This approach worked
Nevertheless, I don't agree that this is the solution. [...]
Thanks for your analysis. You are right, unfortunately :-) However,
it's a lot of work...

Is there an example package with automake and gnulib that uses both C
and C++ similar to ttfautohint, and that I could use as a template?


Werner
Bruno Haible
2017-09-03 14:15:20 UTC
Permalink
Raw Message
Hello Werner,
Post by Werner LEMBERG
Is there an example package with automake and gnulib that uses both C
and C++ similar to ttfautohint, and that I could use as a template?
I don't know of such an example package.

Basically, the steps are to

1) Create a lib/configure.ac that contains everything relevant to the
C code (lib/ directory),
2) Create a frontend/configure.ac that contains everything relevant to the
C++ code (frontend/ directory).
Each with a gnulib-tool invocation. The two gnulib-tool invocations can
share the same build-aux/ directory and gnulib-m4/ directories (at the
top-level directory, likely), but must not share the gnulib-lib/ directory.

3) Test each of these subpackages separately.

You'll have to adjust the -I options in order not to accidentally use
the other subpackage's config.h file.

4) From the top-level configure.ac, remove all that's in the sub-configure.acs.
Instead insert

AC_CONFIG_SUBDIRS([lib frontend])

And, in case your subdir-configures define some options, you have to collect
them:

dnl Ensure that "configure --help" lists all the command line options that
dnl are usable with the subdir configures. Really AC_CONFIG_SUBDIRS should
dnl do it by itself.
dnl System types:
AC_CANONICAL_HOST
dnl Optional Features: AC_ARG_ENABLE calls
dnl Optional Packages: AC_ARG_WITH calls
dnl Some influential environment variables: AC_ARG_VAR calls
esyscmd([{ cd lib && autoconf --trace=AC_ARG_ENABLE:'$n([$1],[$2])' --trace=AC_ARG_WITH:'$n([$1],[$2])' --trace=AC_ARG_VAR:'$n($@)' && cd ..; cd frontend && autoconf --trace=AC_ARG_ENABLE:'$n([$1],[$2])' --trace=AC_ARG_WITH:'$n([$1],[$2])' --trace=AC_ARG_VAR:'$n($@)' && cd ..; } | sed -f build-aux/ac-help.sed ])

Where build-aux/ac-help.sed comes from GNU gettext [1].

I hope this is good enough to give you a good start?

Bruno

[1] http://git.savannah.gnu.org/gitweb/?p=gettext.git;a=blob_plain;f=build-aux/ac-help.sed
Bruno Haible
2017-09-03 16:11:42 UTC
Permalink
Raw Message
Werner, Paul,
Post by Bruno Haible
The other approaches are brittle: If we/you change something regarding
the max_align_t problem, you will continue to see issues
- on other platforms,
- when you request additional gnulib modules,
- when the C standard features change,
- when the C++ standard features change.
* You could add gnulib module 'std-gnu11' to the list of gnulib modules
you request. This has the chance of fixing other problems than the
max_align_t one, because C++ is closer to C11 than it is to C99.
But still, newer C or C++ standard can bring new problems.
* Gnulib could add a dependency from 'stddef' to 'std-gnu11'. I reject
this idea because this is a big change that affects all users, for a
situation that is not supported.
* Gnulib could test something like
HAVE_MAX_ALIGN_T || (defined(__APPLE__) && defined(__MACH__) && defined(__cplusplus))
instead of
HAVE_MAX_ALIGN_T
This is not such a big change, but it is brittle code, may only fix
the max_align_t problem, and is for a situation that is not supported.
There is also the approach that we, in gnulib, usually employ when we have a
"typedef redefinition" error:

diff --git a/lib/stddef.in.h b/lib/stddef.in.h
index 2a11d2b..619f224 100644
--- a/lib/stddef.in.h
+++ b/lib/stddef.in.h
@@ -102,7 +102,8 @@ typedef union
double __d _GL_STDDEF_ALIGNAS (double);
long double __ld _GL_STDDEF_ALIGNAS (long double);
long int __i _GL_STDDEF_ALIGNAS (long int);
-} max_align_t;
+} _gl_max_align_t;
+#define max_align_t _gl_max_align_t
#endif

# endif /* ***@GUARD_PREFIX@_STDDEF_H */


This one is not brittle and is not a big change. If Paul agrees, I would commit
this, and you (Werner) would not need to reorganize your package's configuration.

Bruno
Paul Eggert
2017-09-04 16:57:03 UTC
Permalink
Raw Message
Post by Bruno Haible
+} _gl_max_align_t;
+#define max_align_t _gl_max_align_t
#endif
This one is not brittle and is not a big change. If Paul agrees, I would commit
this, and you (Werner) would not need to reorganize your package's configuration.
Sure, that works for me. Though I expect in the long run Werner will have to
reorganize for some other reason.
Werner LEMBERG
2017-09-05 07:41:38 UTC
Permalink
Raw Message
Post by Bruno Haible
+} _gl_max_align_t;
+#define max_align_t _gl_max_align_t
#endif
This one is not brittle and is not a big change. If Paul agrees, I
would commit this, and you (Werner) would not need to reorganize
your package's configuration.
Sure, that works for me. Though I expect in the long run Werner
will have to reorganize for some other reason.
Indeed, and I'm grateful for Bruno's instructions. However, it will
take time until I actually convince myself that it should be done :-)

I will report back if I have something working so that (a) you can
inspect it, and (b) other projects using C and C++ together can use
this as a template.


Werner
Bruno Haible
2017-09-08 08:05:26 UTC
Permalink
Raw Message
Post by Paul Eggert
Post by Bruno Haible
+} _gl_max_align_t;
+#define max_align_t _gl_max_align_t
#endif
This one is not brittle and is not a big change. If Paul agrees, I would commit
this, and you (Werner) would not need to reorganize your package's configuration.
Sure, that works for me.
OK, here's what I'm committing: the same idiom as we use for wint_t.


2017-09-08 Bruno Haible <***@clisp.org>

stddef: Avoid conflict with system-defined max_align_t.
The configure-determined HAVE_MAX_ALIGN_T may not always be accurate.
Reported by Werner Lemberg <***@gnu.org> in
<https://lists.gnu.org/archive/html/bug-gnulib/2017-08/msg00185.html>.
* lib/stddef.in.h (rpl_max_align_t): Renamed from max_align_t.
(max_align_t): Define as a macro.
(GNULIB_defined_max_align_t): New macro. Guards against multiple
definitions of rpl_max_align_t in different copies of gnulib-generated
<stddef.h>.

diff --git a/lib/stddef.in.h b/lib/stddef.in.h
index 2a11d2b..a79f536 100644
--- a/lib/stddef.in.h
+++ b/lib/stddef.in.h
@@ -85,24 +85,28 @@
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)
+# if !GNULIB_defined_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
using __alignof__ (which returns 8 for double) rather than _Alignof
(which returns 4), and align each union member accordingly. */
-# ifdef __GNUC__
-# define _GL_STDDEF_ALIGNAS(type) \
- __attribute__ ((__aligned__ (__alignof__ (type))))
-# else
-# define _GL_STDDEF_ALIGNAS(type) /* */
-# endif
+# ifdef __GNUC__
+# define _GL_STDDEF_ALIGNAS(type) \
+ __attribute__ ((__aligned__ (__alignof__ (type))))
+# else
+# define _GL_STDDEF_ALIGNAS(type) /* */
+# endif
typedef union
{
char *__p _GL_STDDEF_ALIGNAS (char *);
double __d _GL_STDDEF_ALIGNAS (double);
long double __ld _GL_STDDEF_ALIGNAS (long double);
long int __i _GL_STDDEF_ALIGNAS (long int);
-} max_align_t;
+} rpl_max_align_t;
+# define max_align_t rpl_max_align_t
+# define GNULIB_defined_max_align_t 1
+# endif
#endif

# endif /* ***@GUARD_PREFIX@_STDDEF_H */
Werner LEMBERG
2017-09-11 06:16:51 UTC
Permalink
Raw Message
Post by Bruno Haible
OK, here's what I'm committing: the same idiom as we use for
wint_t. [...]
Thanks!


Werner

Bruno Haible
2017-08-30 07:45:35 UTC
Permalink
Raw Message
Shall I simply add
AC_LANG_PUSH([C++])
right before the call to
gl_INIT
in my `configure.ac' file?
It's worth a try, yes. If it creates other problems, we can look into these.

Bruno
Chris Simpkins
2017-08-30 14:38:30 UTC
Permalink
Raw Message
Full gnulib stddef.h header file requested by Werner available here: https://gist.github.com/chrissimpkins/6e76999d84ca6ff36cf8f7ef047997f4

max_align_t definition from `cat /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/6.1.0/include/stddef.h` on Travis OS X 10.10 builds:

#if __STDC_VERSION__ >= 201112L || __cplusplus >= 201103L
#if !defined(__CLANG_MAX_ALIGN_T_DEFINED) || __has_feature(modules)
#if defined(_MSC_VER)
typedef double max_align_t;
#elif defined(__APPLE__)
typedef long double max_align_t;
#else
// Define 'max_align_t' to match the GCC definition.
typedef struct {
long long __clang_max_align_nonce1
__attribute__((__aligned__(__alignof__(long long))));
long double __clang_max_align_nonce2
__attribute__((__aligned__(__alignof__(long double))));
} max_align_t;
#endif
Post by Bruno Haible
Shall I simply add
AC_LANG_PUSH([C++])
right before the call to
gl_INIT
in my `configure.ac' file?
It's worth a try, yes. If it creates other problems, we can look into these.
Bruno
Loading...