Re: AC_C_NORETURN macro?
On 2012-04-25 10:24:19 -0600, Eric Blake wrote: Right now, gnulib already has not only such a macro, but also a stdnoreturn.h replacement header that supports this functionality for generic C11 compilers and older GCC, as well as working around a bug in MSVC vs. native Windows headers and their use of 'noreturn' in contexts that are incompatible with C11 usage. I'm not sure if it is worth trying to backport the gnulib work into upstream autoconf, or to just recommend that you use the gnulib solution up front (adding a macro, without also adding the code that exploits the macro, as gnulib does with its replacement stdnoreturn.h header, makes the macro harder to use). The gnulib code, as I can see it under Debian, looks strange. In lib/stdnoreturn.in.h: #if 1200 = _MSC_VER /* Standard include files on this platform contain declarations like __declspec (noreturn) void abort (void);. #define noreturn _Noreturn would cause this declaration to be rewritten to the invalid __declspec (__declspec (noreturn)) void abort (void);. Instead, define noreturn to empty, so that such declarations are rewritten to __declspec () void abort (void);, which is equivalent to void abort (void);; this gives up on noreturn's advice to the compiler but at least it is valid code. */ # define noreturn /*empty*/ #else # define noreturn _Noreturn #endif IMHO, the problem with _MSC_VER (which is not a bug, because noreturn wasn't reserved) means that using the stdnoreturn.h header is not the right solution for code that needs to be pre-C11 compatible; indeed some implementations may have another use of noreturn. I think there's also a clash with GCC's __attribute__ ((noreturn)) if it is used by some depencency (e.g. GMP). modules/snippet/_Noreturn references build-aux/snippet/_Noreturn.h, which is: #ifndef _Noreturn # if (3 = __GNUC__ || (__GNUC__ == 2 8 = __GNUC_MINOR__) \ || 0x5110 = __SUNPRO_C) # define _Noreturn __attribute__ ((__noreturn__)) # elif 1200 = _MSC_VER # define _Noreturn __declspec (noreturn) # else # define _Noreturn # endif #endif but I don't see how it can be correct on a non-GCC non-SunPro C11 implementation: _Noreturn would get defined to nothing; the code would be valid, but the C11 _Noreturn function specifier would not be used. I had changed the MPFR code to: * Autoconf part: dnl Check for _Noreturn function specifier (ISO C11) AC_CACHE_CHECK([for _Noreturn], mpfr_cv_have_noreturn, [ AC_COMPILE_IFELSE([AC_LANG_SOURCE([[_Noreturn void foo(int);]])], mpfr_cv_have_noreturn=yes, mpfr_cv_have_noreturn=no) ]) if test $mpfr_cv_have_noreturn = yes; then AC_DEFINE(MPFR_HAVE_NORETURN,1,[Define if the _Noreturn function specifier is supported.]) fi * The internal header part (mpfr-impl.h): #if defined(MPFR_HAVE_NORETURN) /* _Noreturn is specified by ISO C11 (Section 6.7.4); in GCC, it is supported as of version 4.7. */ # define MPFR_NORETURN _Noreturn #elif __MPFR_GNUC(3,0) || __MPFR_ICC(8,1,0) # define MPFR_NORETURN __attribute__ ((noreturn)) #else # define MPFR_NORETURN #endif I think that something like #elif 1200 = _MSC_VER # define MPFR_NORETURN __declspec (noreturn) could be added. And perhaps it would be better to add !defined(noreturn) for the GCC and MSVC cases. -- Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: [FYI] {master} refactor: use modern semantics of 'open'
Hi Eric, sorry for the delay.
On 04/25/2012 01:25 AM, Eric Blake wrote:
Actually, this appears to make _all_ the XFile uses work; all that
remains broken is places such as bin/autoupdate.in calling raw open
instead of using XFile.
diff --git i/lib/Autom4te/XFile.pm w/lib/Autom4te/XFile.pm
index 19b73aa..95a452b 100644
--- i/lib/Autom4te/XFile.pm
+++ w/lib/Autom4te/XFile.pm
@@ -138,7 +138,14 @@ sub open
# comment in IO::Handle.
${*$fh}{'autom4te_xfile_file'} = $file;
- if (!$fh-SUPER::open (@_))
+ if (defined $mode $file eq '-')
+{
+ if (!$fh-SUPER::open ($mode$file))
What if mode is something like w or r+?
+ {
+ fatal cannot open $file: $!;
+ }
+}
+ elsif (!$fh-SUPER::open (@_))
In other words, since the point of XFile is to ensure binmode, and to
make open nicer to use, making XFile the owner of '-' magic seems like
the right thing to do, and the real remaining autoconf bug is that we
aren't using XFile everywhere.
Makes sense.
If anything, this issue shows that the Automake::XFile module (and
other similar modules as well) should live in their own git
repository, which both Autoconf and Automake should use as a
submodule -- and which (for $DEITY's sake!), should be unit-tested.
Any volunteer?
Alas, my perl-fu is weak enough that I'm not sure how good my
unit-testing attempts would be. But moving the files to a common
repository seems doable (how about gnulib?).
This could be a good interim solution, as I the paperwork in place for
Gnulib, as well as pushing rights for its repository. Unit tests can be
added later, as the need arise, and/or slowly step-by-step when we feel
like doing so.
Thanks,
Stefano
___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf
Re: AC_C_NORETURN macro?
On 04/26/2012 02:54 AM, Vincent Lefevre wrote: The gnulib code, as I can see it under Debian, looks strange. In lib/stdnoreturn.in.h: #if 1200 = _MSC_VER /* Standard include files on this platform contain declarations like __declspec (noreturn) void abort (void);. #define noreturn _Noreturn would cause this declaration to be rewritten to the invalid __declspec (__declspec (noreturn)) void abort (void);. Instead, define noreturn to empty, so that such declarations are rewritten to __declspec () void abort (void);, which is equivalent to void abort (void);; this gives up on noreturn's advice to the compiler but at least it is valid code. */ # define noreturn /*empty*/ #else # define noreturn _Noreturn #endif IMHO, the problem with _MSC_VER (which is not a bug, because noreturn wasn't reserved) means that using the stdnoreturn.h header is not the right solution for code that needs to be pre-C11 compatible; If I write C11 code: #include stdnoreturn.h #include stdio.h then I expect things to work. But _MSC_VER system headers use noreturn in a non-C11 manner, such that the only way for this to work via gnulib is to make 'noreturn' a no-op on that platform, until such time as Microsoft updates their headers. Microsoft has a history of namespace pollution; had their compiler used '__declspec (__noreturn)' instead of '__declspec (noreturn)', we would not be facing this clash. The whole point of gnulib is to give me enough support so that I can write code that is valid C11, and also which compiles under non-C11 compilers, without any extra #ifdef work in my code (since gnulib took care of it for me). indeed some implementations may have another use of noreturn. Not if they were compliant to C99 (since C99 didn't reserve 'noreturn', then system headers under C99 mode should not be using that symbol). but I don't see how it can be correct on a non-GCC non-SunPro C11 implementation: _Noreturn would get defined to nothing; the code would be valid, but the C11 _Noreturn function specifier would not be used. Correct. _Noreturn is an optimization hint; your code will still function correctly if the specifier is not present. The gnulib choice to define it away on problematic systems is intentional. -- Eric Blake ebl...@redhat.com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: [FYI] {master} refactor: use modern semantics of 'open'
On 04/26/2012 05:12 AM, Stefano Lattarini wrote:
Hi Eric, sorry for the delay.
On 04/25/2012 01:25 AM, Eric Blake wrote:
Actually, this appears to make _all_ the XFile uses work; all that
remains broken is places such as bin/autoupdate.in calling raw open
instead of using XFile.
diff --git i/lib/Autom4te/XFile.pm w/lib/Autom4te/XFile.pm
index 19b73aa..95a452b 100644
--- i/lib/Autom4te/XFile.pm
+++ w/lib/Autom4te/XFile.pm
@@ -138,7 +138,14 @@ sub open
# comment in IO::Handle.
${*$fh}{'autom4te_xfile_file'} = $file;
- if (!$fh-SUPER::open (@_))
+ if (defined $mode $file eq '-')
+{
+ if (!$fh-SUPER::open ($mode$file))
What if mode is something like w or r+?
I hadn't thought about that - but we would indeed need to add some
smarts to XFile to handle it properly.
In other words, since the point of XFile is to ensure binmode, and to
make open nicer to use, making XFile the owner of '-' magic seems like
the right thing to do, and the real remaining autoconf bug is that we
aren't using XFile everywhere.
Makes sense.
If anything, this issue shows that the Automake::XFile module (and
other similar modules as well) should live in their own git
repository, which both Autoconf and Automake should use as a
submodule -- and which (for $DEITY's sake!), should be unit-tested.
Any volunteer?
Alas, my perl-fu is weak enough that I'm not sure how good my
unit-testing attempts would be. But moving the files to a common
repository seems doable (how about gnulib?).
This could be a good interim solution, as I the paperwork in place for
Gnulib, as well as pushing rights for its repository. Unit tests can be
added later, as the need arise, and/or slowly step-by-step when we feel
like doing so.
Would we move all .pm files, or just the .pm files that both automake
and autoconf are sharing? (The list of shared files is:
Configure_ac.pm, Channels.pm, FileUtils.pm, Getopt.pm, XFile.pm)
--
Eric Blake ebl...@redhat.com+1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf
Re: AC_C_NORETURN macro?
On 2012-04-26 08:14:51 -0600, Eric Blake wrote: If I write C11 code: #include stdnoreturn.h #include stdio.h then I expect things to work. But _MSC_VER system headers use noreturn in a non-C11 manner, such that the only way for this to work via gnulib is to make 'noreturn' a no-op on that platform, until such time as Microsoft updates their headers. Microsoft has a history of namespace pollution; had their compiler used '__declspec (__noreturn)' instead of '__declspec (noreturn)', we would not be facing this clash. GCC has the same kind of problem. Though the __ version can also be used, it is poorly documented, and examples have the version without __. And some libraries under GNU/Linux reuse this version without __. The whole point of gnulib is to give me enough support so that I can write code that is valid C11, and also which compiles under non-C11 compilers, without any extra #ifdef work in my code (since gnulib took care of it for me). In MPFR, we want more: to be able to use the C99/C11 features and extensions from compilers (because the feature is not in the C standard or is too recent for the compilers). Not only the fact that the code compiles, but also that the feature is used. indeed some implementations may have another use of noreturn. Not if they were compliant to C99 (since C99 didn't reserve 'noreturn', then system headers under C99 mode should not be using that symbol). Almost no compilers/systems are compliant to C99. For instance, under Linux, GCC defines unix and linux to 1, while they are not reserved. but I don't see how it can be correct on a non-GCC non-SunPro C11 implementation: _Noreturn would get defined to nothing; the code would be valid, but the C11 _Noreturn function specifier would not be used. Correct. _Noreturn is an optimization hint; your code will still function correctly if the specifier is not present. The gnulib choice to define it away on problematic systems is intentional. If I understand the gnulib code, gnulib defines it away also on pure C11 implementations (and not complete implementations that understand _Noreturn), which are not problematic systems! #ifndef _Noreturn # if (3 = __GNUC__ || (__GNUC__ == 2 8 = __GNUC_MINOR__) \ || 0x5110 = __SUNPRO_C) # define _Noreturn __attribute__ ((__noreturn__)) # elif 1200 = _MSC_VER # define _Noreturn __declspec (noreturn) # else # define _Noreturn # endif #endif -- Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: AC_C_NORETURN macro?
On 04/26/2012 09:02 AM, Vincent Lefevre wrote: On 2012-04-26 08:14:51 -0600, Eric Blake wrote: If I write C11 code: #include stdnoreturn.h #include stdio.h then I expect things to work. But _MSC_VER system headers use noreturn in a non-C11 manner, such that the only way for this to work via gnulib is to make 'noreturn' a no-op on that platform, until such time as Microsoft updates their headers. Microsoft has a history of namespace pollution; had their compiler used '__declspec (__noreturn)' instead of '__declspec (noreturn)', we would not be facing this clash. GCC has the same kind of problem. Though the __ version can also be used, it is poorly documented, and examples have the version without __. And some libraries under GNU/Linux reuse this version without __. Any installed header that does not use the __ version is buggy. Thankfully, in the open source world, you can post bug reports and patches to get those buggy packages fixed; which is a much different story than for the proprietary _MSC_VER system headers. The whole point of gnulib is to give me enough support so that I can write code that is valid C11, and also which compiles under non-C11 compilers, without any extra #ifdef work in my code (since gnulib took care of it for me). In MPFR, we want more: to be able to use the C99/C11 features and extensions from compilers (because the feature is not in the C standard or is too recent for the compilers). Not only the fact that the code compiles, but also that the feature is used. Fair enough. But then check directly for that feature, instead of asking gnulib to do it for you, and feel free to use gnulib's checks as a starting point. And I'm still not convinced that we are ready to promote this into an autoconf macro quite yet; on the other hand, if we had someone working on improving the family of C macros to make it easier to tell C89, C99, and now C11 apart, as well as allowing packages to specify which flavor of language they are specifically targetting, then at that point, AC_C_NORETURN might make sense as a part of probing for C11. Not if they were compliant to C99 (since C99 didn't reserve 'noreturn', then system headers under C99 mode should not be using that symbol). Almost no compilers/systems are compliant to C99. For instance, under Linux, GCC defines unix and linux to 1, while they are not reserved. Even when in --std=c99 mode? I can understand this in --std=gnu99 mode (since gnu99 explicitly allows extensions). This particular pollution is rather pervasive due to historical practice, but if it bothers you that much, I'm sure you could file a bug report, and that someone working on gcc or glibc might be willing to help you address it. Correct. _Noreturn is an optimization hint; your code will still function correctly if the specifier is not present. The gnulib choice to define it away on problematic systems is intentional. If I understand the gnulib code, gnulib defines it away also on pure C11 implementations (and not complete implementations that understand _Noreturn), which are not problematic systems! You missed an aspect - gnulib only provides a replacement stdnoreturn.h header on non-C11 systems; on systems where the system header is compliant, there is no need for gnulib to interject a replacement. Therefore, under C11, gnulib is not defining anything away. -- Eric Blake ebl...@redhat.com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: [FYI] {master} refactor: use modern semantics of 'open'
[SNIP] Eric Blake wrote: Alas, my perl-fu is weak enough that I'm not sure how good my unit-testing attempts would be. But moving the files to a common repository seems doable (how about gnulib?). I replied: This could be a good interim solution, as I the paperwork in place for Gnulib, as well as pushing rights for its repository. Unit tests can be added later, as the need arise, and/or slowly step-by-step when we feel like doing so. Eric replied: Would we move all .pm files, or just the .pm files that both automake and autoconf are sharing? (The list of shared files is: Configure_ac.pm, Channels.pm, FileUtils.pm, Getopt.pm, XFile.pm) I'd move only the shared files as a first step, for sake of simplicity. Once more syncing and testing infrastructure is in place, we might decide to move other files as well (if that will be deemed to offer some advantage). No need to hurry or overdo, right? Thanks, Stefano ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: AC_C_NORETURN macro?
On 2012-04-26 09:15:53 -0600, Eric Blake wrote: On 04/26/2012 09:02 AM, Vincent Lefevre wrote: On 2012-04-26 08:14:51 -0600, Eric Blake wrote: If I write C11 code: #include stdnoreturn.h #include stdio.h then I expect things to work. But _MSC_VER system headers use noreturn in a non-C11 manner, such that the only way for this to work via gnulib is to make 'noreturn' a no-op on that platform, until such time as Microsoft updates their headers. Microsoft has a history of namespace pollution; had their compiler used '__declspec (__noreturn)' instead of '__declspec (noreturn)', we would not be facing this clash. GCC has the same kind of problem. Though the __ version can also be used, it is poorly documented, and examples have the version without __. And some libraries under GNU/Linux reuse this version without __. Any installed header that does not use the __ version is buggy. Thankfully, in the open source world, you can post bug reports and patches to get those buggy packages fixed; This is an optimistic view. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=619933 (that's for the GCC documentation first). Also, there's the problem that fixing old code may introduce new bugs. In MPFR, we want more: to be able to use the C99/C11 features and extensions from compilers (because the feature is not in the C standard or is too recent for the compilers). Not only the fact that the code compiles, but also that the feature is used. Fair enough. But then check directly for that feature, instead of asking gnulib to do it for you, My original question was against autoconf (which already provides macros for similar features), not gnulib. and feel free to use gnulib's checks as a starting point. And I'm still not convinced that we are ready to promote this into an autoconf macro quite yet; on the other hand, if we had someone working on improving the family of C macros to make it easier to tell C89, C99, and now C11 apart, as well as allowing packages to specify which flavor of language they are specifically targetting, then at that point, AC_C_NORETURN might make sense as a part of probing for C11. Not really. Implementations (like GCC/glibc) may start to support C11 while they do not support C99 completely, e.g. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34678 Autoconf should work on a feature basis, not on ISO C version information (which is unreliable). Not if they were compliant to C99 (since C99 didn't reserve 'noreturn', then system headers under C99 mode should not be using that symbol). Almost no compilers/systems are compliant to C99. For instance, under Linux, GCC defines unix and linux to 1, while they are not reserved. Even when in --std=c99 mode? No, but we want to be able to compile our code with --std=gnu99. This is needed to get some extra (optional) features. We have no problem with that, but this shows you that compilers are not perfect. Correct. _Noreturn is an optimization hint; your code will still function correctly if the specifier is not present. The gnulib choice to define it away on problematic systems is intentional. If I understand the gnulib code, gnulib defines it away also on pure C11 implementations (and not complete implementations that understand _Noreturn), which are not problematic systems! You missed an aspect - gnulib only provides a replacement stdnoreturn.h header on non-C11 systems; on systems where the system header is compliant, there is no need for gnulib to interject a replacement. Therefore, under C11, gnulib is not defining anything away. Ah, OK. But I think that stdnoreturn.h is not a solution for MPFR, due to the potential clashes with GMP (on which we depend), which uses GCC's __attribute__ ((noreturn)). Though this may be fixed in the future, problems would still appear with older versions. Thus we should use _Noreturn directly, when supported. -- Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: AC_C_NORETURN macro?
On 2012-04-26 17:56 +0200, Vincent Lefevre wrote: On 2012-04-26 09:15:53 -0600, Eric Blake wrote: On 04/26/2012 09:02 AM, Vincent Lefevre wrote: On 2012-04-26 08:14:51 -0600, Eric Blake wrote: Correct. _Noreturn is an optimization hint; your code will still function correctly if the specifier is not present. The gnulib choice to define it away on problematic systems is intentional. If I understand the gnulib code, gnulib defines it away also on pure C11 implementations (and not complete implementations that understand _Noreturn), which are not problematic systems! You missed an aspect - gnulib only provides a replacement stdnoreturn.h header on non-C11 systems; on systems where the system header is compliant, there is no need for gnulib to interject a replacement. Therefore, under C11, gnulib is not defining anything away. Ah, OK. But I think that stdnoreturn.h is not a solution for MPFR, due to the potential clashes with GMP (on which we depend), which uses GCC's __attribute__ ((noreturn)). Though this may be fixed in the future, problems would still appear with older versions. Thus we should use _Noreturn directly, when supported. Another alternative is to simply make sure that you always include the GMP headers before including stdnoreturn.h. Cheers, -- Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/) ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: AC_C_NORETURN macro?
Eric Blake ebl...@redhat.com writes: On 04/26/2012 09:02 AM, Vincent Lefevre wrote: Almost no compilers/systems are compliant to C99. For instance, under Linux, GCC defines unix and linux to 1, while they are not reserved. Even when in --std=c99 mode? That, or -ansi, make GCC and glibc compliant, but almost no one uses them. The experience of trying to use them with a large project will quickly show why. It's almost impossible to get the right set of feature-test macros defined to let the code build without causing other strange problems on other platforms, due to bugs in their strict standard compliance mode or due to other weirdness (try, for example, requesting _XOPEN_SOURCE 600 on Solaris, and you'll find you have to go to some lengths to ensure that the source code and the compiler are configured for consistently using the same standard or the system header files will throw fatal errors and abort the compile). I've done the experiment from time to time of supporting -ansi or --std=c99, but even for small code bases I consider it the kind of thing that one does as a hobby or out of curiosity. It's not a very good way to actually get work done and write code that is portable on a practical level (meaning that people on multiple UNIX platforms can just run ./configure make). -- Russ Allbery (r...@stanford.edu) http://www.eyrie.org/~eagle/ ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: AC_CHECK_ALIGNOF fails when cross-compiling with gcc = 4.5
On Wed, Apr 25, 2012 at 10:34:18AM -0600, Eric Blake wrote: On 04/25/2012 02:56 AM, Michael Olbrich wrote: when cross-compiling with gcc = 4.5 (I think), AC_CHECK_ALIGNOF fails to detect the alignment. This happens because the compiler fails with error: storage size of ‘test_array’ isn’t constant instead of succeeding. Thanks for the report. Alas, you just missed the release autoconf 2.69, so if this turns out to be an autoconf bug, you have the honor of the first bug report on the new release (even though the problem itself is older). Using __builtin_offsetof helps. Patch attached. I'm not quite sure when __builtin_offsetof should be used, but it is used in the Linux kernel for gcc 4.x, so I think this is correct. Thanks for the attempted patch. However, the real bug is that we are trying to use our own offsetof, instead of relying on the system headers to do the heavy lifting on our behalf. That is, stddef.h should already by using __builtin_offsetof, and we should be turning to stddef.h rather than reinventing the work in autoconf. +++ b/lib/autoconf/types.m4 @@ -800,8 +800,12 @@ m4_define([_AC_CHECK_ALIGNOF], _AC_CACHE_CHECK_INT([alignment of $1], [AS_TR_SH([ac_cv_alignof_$3])], [(long int) offsetof (ac__type_alignof_, y)], [AC_INCLUDES_DEFAULT([$2]) Normally, AC_INCLUDES_DEFAULT should already be including stddef.h; the only time this is not true is if $2 is non-empty (you were providing specific headers to include instead of relying on the defaults). And once stddef.h is in the picture, While AC_INCLUDES_DEFAULT is in $2 this put me on the right track. The problem ist that STDC_HEADERS is not defined. -#ifndef offsetof -# define offsetof(type, member) ((char *) ((type *) 0)-member - (char *) 0) offsetof should already be defined for gcc compilers, at which point, this fallback is good enough for non-compliant platforms with older compilers that don't warn like gcc does. So the real question is: how did you trigger this failure in the first place, and could it be a bug in your configure.ac that resulted in the $2 argument passed to _AC_CHECK_ALIGNOF overriding the AC_INCLUDES_DEFAULT in such a manner that stddef.h is not being included? Can you post both a configure.ac that reproduces the problem, and the corresponding config.log that shows how what program was actually being compiled when you hit the gcc warning? http://git.gnome.org/browse/glib/tree/configure.ac#n3451 From what I can tell, the code needed to define STDC_HEADERS is generated for the first AC_CHECK_HEADER. In this case for zlib.h: http://git.gnome.org/browse/glib/tree/configure.ac#n466 However this is only executed for 'test x$found_zlib = xno', so STDC_HEADERS is never defined. If I put an unconditional AC_CHECK_HEADER before the zlib stuff, then STDC_HEADERS is defined and AC_CHECK_ALIGNOF works as expected. Michael -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | signature.asc Description: Digital signature
Re: AC_CHECK_ALIGNOF fails when cross-compiling with gcc = 4.5
On Thu, Apr 26, 2012 at 09:15:09AM +0200, Michael Olbrich wrote: On Wed, Apr 25, 2012 at 10:34:18AM -0600, Eric Blake wrote: On 04/25/2012 02:56 AM, Michael Olbrich wrote: when cross-compiling with gcc = 4.5 (I think), AC_CHECK_ALIGNOF fails to detect the alignment. This happens because the compiler fails with error: storage size of ‘test_array’ isn’t constant instead of succeeding. Thanks for the report. Alas, you just missed the release autoconf 2.69, so if this turns out to be an autoconf bug, you have the honor of the first bug report on the new release (even though the problem itself is older). Using __builtin_offsetof helps. Patch attached. I'm not quite sure when __builtin_offsetof should be used, but it is used in the Linux kernel for gcc 4.x, so I think this is correct. Thanks for the attempted patch. However, the real bug is that we are trying to use our own offsetof, instead of relying on the system headers to do the heavy lifting on our behalf. That is, stddef.h should already by using __builtin_offsetof, and we should be turning to stddef.h rather than reinventing the work in autoconf. +++ b/lib/autoconf/types.m4 @@ -800,8 +800,12 @@ m4_define([_AC_CHECK_ALIGNOF], _AC_CACHE_CHECK_INT([alignment of $1], [AS_TR_SH([ac_cv_alignof_$3])], [(long int) offsetof (ac__type_alignof_, y)], [AC_INCLUDES_DEFAULT([$2]) Normally, AC_INCLUDES_DEFAULT should already be including stddef.h; the only time this is not true is if $2 is non-empty (you were providing specific headers to include instead of relying on the defaults). And once stddef.h is in the picture, While AC_INCLUDES_DEFAULT is in $2 this put me on the right track. The problem ist that STDC_HEADERS is not defined. -#ifndef offsetof -# define offsetof(type, member) ((char *) ((type *) 0)-member - (char *) 0) offsetof should already be defined for gcc compilers, at which point, this fallback is good enough for non-compliant platforms with older compilers that don't warn like gcc does. So the real question is: how did you trigger this failure in the first place, and could it be a bug in your configure.ac that resulted in the $2 argument passed to _AC_CHECK_ALIGNOF overriding the AC_INCLUDES_DEFAULT in such a manner that stddef.h is not being included? Can you post both a configure.ac that reproduces the problem, and the corresponding config.log that shows how what program was actually being compiled when you hit the gcc warning? http://git.gnome.org/browse/glib/tree/configure.ac#n3451 From what I can tell, the code needed to define STDC_HEADERS is generated for the first AC_CHECK_HEADER. In this case for zlib.h: http://git.gnome.org/browse/glib/tree/configure.ac#n466 However this is only executed for 'test x$found_zlib = xno', so STDC_HEADERS is never defined. If I put an unconditional AC_CHECK_HEADER before the zlib stuff, then STDC_HEADERS is defined and AC_CHECK_ALIGNOF works as expected. I've attached a minimalistic configure.ac that demonstrated the problem. That should be easier than the one from glib. Regards, Michael Olbrich -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | AC_PREREQ([2.68]) AC_INIT([foo],[1],[m.olbr...@pengutronix.de]) AC_CONFIG_SRCDIR([configure.ac]) AC_PROG_CC if false; then AC_CHECK_HEADER(stdint.h) fi AC_CHECK_TYPE([unsigned long]) AC_CHECK_ALIGNOF([unsigned long]) signature.asc Description: Digital signature
go.m4 in autoconf-2.69 assumes old os.Open API
Hi,
In autoconf-2.69/lib/autoconf/go.m4, two of the test Go programs do the
following to open a file for output:
f, err := os.Open(conftest.out, os.O_CREATE|os.O_WRONLY, 0777)
However, os.Open has changed in recent versions of Go. In Go 1 as
implemented in GCC 4.7, it only takes one argument. Compare:
http://web.archive.org/web/20100210113321/http://golang.org/pkg/os/#File.Open
http://web.archive.org/web/20110520214350/http://golang.org/pkg/os/#File.Open
So currently autoconf-2.69's testsuite fails on a machine with GCC 4.7:
the go.at test finds gccgo but can't compile anything with it. It works
if you change both of those calls to do:
f, err := os.Create(conftest.out)
(e.g. with the attached patch) but that then won't work with older
versions of GCC. I'm not sure what the best fix would be here.
Thanks,
--
Adam Sampson a...@offog.org http://offog.org/
os.Open doesn't exist in multi-argument form in recent versions of Go.
diff -x config.log -x config.status -ru tmp/autoconf-2.69/lib/autoconf/go.m4
work/autoconf-2.69/lib/autoconf/go.m4
--- tmp/autoconf-2.69/lib/autoconf/go.m42012-01-21 13:46:39.0
+
+++ work/autoconf-2.69/lib/autoconf/go.m4 2012-04-26 12:55:17.535998327
+0100
@@ -61,7 +61,7 @@
# Produce source that performs I/O.
m4_define([_AC_LANG_IO_PROGRAM(Go)],
[AC_LANG_PROGRAM([import ( fmt; os )],
-[f, err := os.Open(conftest.out, os.O_CREATE|os.O_WRONLY, 0777)
+[f, err := os.Create(conftest.out)
if err != nil {
fmt.Println(err)
os.Exit(1)
@@ -107,7 +107,7 @@
os
)
],
-[f, err := os.Open(conftest.val, os.O_CREATE|os.O_WRONLY, 0777)
+[f, err := os.Create(conftest.val)
if err != nil {
os.Exit(1)
}
Re: AC_CHECK_ALIGNOF fails when cross-compiling with gcc = 4.5
On 04/26/2012 02:03 AM, Michael Olbrich wrote: While AC_INCLUDES_DEFAULT is in $2 this put me on the right track. The problem ist that STDC_HEADERS is not defined. From what I can tell, the code needed to define STDC_HEADERS is generated for the first AC_CHECK_HEADER. In this case for zlib.h: http://git.gnome.org/browse/glib/tree/configure.ac#n466 However this is only executed for 'test x$found_zlib = xno', so STDC_HEADERS is never defined. If I put an unconditional AC_CHECK_HEADER before the zlib stuff, then STDC_HEADERS is defined and AC_CHECK_ALIGNOF works as expected. I've attached a minimalistic configure.ac that demonstrated the problem. That should be easier than the one from glib. AC_PREREQ([2.68]) AC_INIT([foo],[1],[m.olbr...@pengutronix.de]) AC_CONFIG_SRCDIR([configure.ac]) AC_PROG_CC if false; then AC_CHECK_HEADER(stdint.h) Yep. That's indeed a bug in your configure.ac, and nothing that autoconf can do about it without your help. One thing that is possible to keep the actual header check conditional, but making all the prerequisites (such as the side effect of setting STDC_HEADERS) unconditional, would be to rewrite this as: AS_IF([false], [AC_CHECK_HEADER([stdint.h])]) to rely on the documented property of AS_IF of hoisting prerequisites outside the conditional. -- Eric Blake ebl...@redhat.com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: autoconf implementation for powl()
On 04/26/2012 11:26 AM, Tom Vijlbrief wrote:
Autoconf 2.67 uses the following code to test for powl():
Thanks for the report. However, you are mistaken, as autoconf does not
test for powl() at all ('git grep powl' has zero hits). Rather, this is
a bug in the configure.ac of the package you are trying to compile.
int value = powl (1.0, 1.0);
It looks like a copy/paste error from fabsl(long double)
You will need to report this bug to the package in question.
--
Eric Blake ebl...@redhat.com+1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
