bug-autoconf
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: AC_CHECK_ALIGNOF fails when cross-compiling with gcc >= 4.5


From: Michael Olbrich
Subject: Re: AC_CHECK_ALIGNOF fails when cross-compiling with gcc >= 4.5
Date: Thu, 26 Apr 2012 10:03:11 +0200
User-agent: Mutt/1.5.20 (2009-06-14)

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-5555 |

Attachment: configure.ac
Description: Text document

Attachment: signature.asc
Description: Digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]