Eric Blake wrote:
> If I understand the issue
> correctly, then if your gcc supports -fgnu89-inline, you can work around the
> issue by specifying CFLAGS='-fgnu89-inline' at configure time.
Indeed, excellent! This is the workaround that is easiest to apply.
The -fgnu89-inline has the desired eff
Bruno Haible clisp.org> writes:
> > > + if test $gl_cv_header_wchar_h_correct_inline = no; then
> > > +AC_MSG_ERROR([ cannot be used with this compiler ($CC
$CFLAGS).
> >
> > Must we error out, or can we use AC_DEFINE/AC_SUBST to make our
> > substitute work around the problem by never c
Hi Eric,
> > @@ -34,6 +34,8 @@
> > WCHAR_H=wchar.h
> >fi
> >
> > + gl_WCHAR_H_INLINE_OK
>
> Why not AC_REQUIRE it here?
Ok, I can use AC_REQUIRE here.
> > + if test $gl_cv_header_wchar_h_correct_inline = no; then
> > +AC_MSG_ERROR([ cannot be used with this compiler ($CC
> > $C
Karl Berry wrote:
> [Limiting to gnulib]
>
> + - Don't use the flags -std=c99 or -std=gnu99.
>
> This is not a realistic option as far as I can tell.
There are three ways out. Yes, in some cases, one or the other is
unrealistic, and the user will have to consider the other ones. The
best we
Bruno Haible clisp.org> writes:
> Here is a proposed change to m4/wchar.m4 that diagnoses the problem before
> the btowc test program is even compiled.
Yes, that is a nicer approach.
> AC_DEFUN([gl_WCHAR_H],
> [
> @@ -34,6 +34,8 @@
> WCHAR_H=wchar.h
>fi
>
> + gl_WCHAR_H_INLINE_OK
[Limiting to gnulib]
+ - Don't use the flags -std=c99 or -std=gnu99.
This is not a realistic option as far as I can tell. As the user, I
never specified -std=gnu99. coreutils and/or gnulib and/or gcc
"helpfully" inserted it somewhere, somehow. I have no practical way
(that I can see) to o
Jim Meyering meyering.net> writes:
> > +int (*signature_check) (void (*) (void)) = atexit;
>
> I haven't looked carefully at each or tested, but...
> please use the "static" attribute on all of those,
> as in your example above.
I thought about that, but with:
+static int (*signature_check) (
> > Any objections to the following?
> > + * m4/btowc.m4 (gl_FUNC_BTOWC): Add a timeout.
> > + * doc/posix-functions/btowc.texi (btowc): Document the problem.
Here is a proposed change to m4/wchar.m4 that diagnoses the problem before
the btowc test program is even compiled.
2009-12-2
Eric Blake wrote:
> Jim Meyering meyering.net> writes:
>
>> > +static int (*check) (char const *, int, char const *) = symlinkat;
>> > +
>> > in order to validate that a function is correctly declared when the user
>> > includes just the one header named in the standards. We can then fix the
>> >
Eric Blake wrote:
> > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42440
In summary, when a glibc version 2.3.x to 2.5 is used with a gcc version
4.3 or newer, the use of __inline in leads to multiple
misbehaviours:
- miscompilation, as observed by Karl,
- link errors, as observed here:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Karl Berry on 12/21/2009 4:51 PM:
> It's definitely a compiler problem. That extern inline asm alias trickery
>
> The gcc people say that the behavior is correct; not a bug.
> (I don't understand all of their replies, but the conclusi
Eric Blake wrote:
> According to Jim Meyering on 12/22/2009 3:21 AM:
>> Eric Blake wrote:
>>> Yep - it is indeed an example of the mtime (and ctime) failing to update,
>>> even though utimensat claimed success.
>>
>> Here's an interesting glibc change from just a few hours ago:
>>
>> http://sources
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Jim Meyering on 12/22/2009 3:21 AM:
> Eric Blake wrote:
>> Yep - it is indeed an example of the mtime (and ctime) failing to update,
>> even though utimensat claimed success.
>
> Here's an interesting glibc change from just a few hours ag
Eric Blake wrote:
> +static int (*check) (char const *, int, char const *) = symlinkat;
> +
> #include
> #include
> #include
>
> in order to validate that a function is correctly declared when the user
> includes just the one header named in the standards. We can then fix the
> fallout by ma
14 matches
Mail list logo
