-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
[adding bug-gnulib]
According to Matthew Woehlke on 3/19/2009 3:07 PM:
> Jim Meyering wrote:
>> Matthew Woehlke wrote:
>>> Also, here is a different (AIX-only) error:
>>>
>>> cc -qlanglvl=ansi -qlanglvl=ansi -g -o ln ln.o libver.a
>>> ../lib/libcoreutils.a /home/install/gnu/rs6000_aix/lib/libintl.a
>>> -lpthread -lc ../lib/libcoreutils.a
>>> source='ls.c' object='ls.o' libtool=no \
>>> DEPDIR=.deps depmode=aix /bin/sh ../build-aux/depcomp \
>>> cc -qlanglvl=ansi -qlanglvl=ansi -I. -I../lib -I../lib
>>> -I/home/install/gnu/rs6000_aix/include -g -c ls.c
>>> "ls.c", line 715.8: 1506-112 (E) Duplicate type qualifier "volatile"
>>> ignored.
>>> "ls.c", line 719.8: 1506-112 (E) Duplicate type qualifier "volatile"
>>> ignored.
>>> make[3]: *** [ls.o] Error 1
>>>
>>> I just ran into this also with some other package (possibly gettext or
>>> subversion*); might call for a fix at a higher level (gnulib or
>>> autoconf?). sig_atomic_t is already volatile on AIX (I checked last
>>> time) so the extra 'volatile' should just be dropped. Maybe something
>>> like:
>>>
>>> #if SIG_ATOMIC_T_IS_VOLATILE
>>> #define SIG_ATOMIC_T_VOLATILE sig_atomic_t
>>> #else
>>> #define SIG_ATOMIC_T_VOLATILE volatile sig_atomic_t
>>> #endif
>>
>> We really don't want to impose that on every application
>> that uses sig_atomic_t.
>>
>> Can you find out where they define or typedef sig_atomic_t?
>
> This?
> $ find /usr/include | xargs grep sig_atomic_t
> /usr/include/sys/signal.h:typedef volatile int sig_atomic_t;
POSIX states this (borrowed from C99):
sig_atomic_t
Possibly volatile-qualified integer type of an object that can be
accessed as an atomic entity, even in the presence of asynchronous interrupts.
But C99 also states:
If the same qualifier appears more than once in the same
specifier-qualifier-list, either directly or via one or more typedefs, the
behavior is the same as if it appeared only once.
Therefore, 'volatile sig_atomic_t' is not a bug, even if sig_atomic_t
already included volatile in its typedef. So the real solution here is to
enhance a .m4 test to detect your compiler's bug in refusing to compile
something that the C standard requires, and write a gnulib replacement
<sys/types.h> and/or <signal.h> that does:
typedef <same-sized-type> rpl_sig_atomic_t;
#define sig_atomic_t rpl_sig_atomic_t
- --
Don't work too hard, make some time for fun as well!
Eric Blake e...@byu.net
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAknDjHsACgkQ84KuGfSFAYCP9ACfSJsSgB0zwT50juUTNpJN5H6G
gnoAn3V9YIRuyaU5iSHZERsGuaWXDnin
=i8Rc
-----END PGP SIGNATURE-----
_______________________________________________
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
