Red Hat Bugzilla – Bug 103255
signal related headers inconsistent, strange defines lead to problems on Itanium systems
Last modified: 2007-11-30 17:06:57 EST
Description of problem:
some software using the signal.h header can't be compiled
on Itanium systems. Assume a file a.c containing only
the #include <signal.h> , compile it:
gcc -c a.c
then you see the following error message:
In file included from /usr/include/signal.h:341,
/usr/include/bits/sigstack.h:57: redefinition of `struct sigaltstack'
Another problem also only on ia64 has to do with the enum
in sigstack.h line 34+. SS_ONSTACK and SS_DISABLE are already
defined in /usr/include/asm/signal.h . sigstack.h may be included
later so after preprocessing the compiler finally sees:
1 = 1,
leading to barfing. in my opinion the enum for ss_flags is
Version-Release number of selected component (if applicable):
glibc-2.3.2-69 through glibc-2.3.2-77
Steps to Reproduce:
1. echo '#include <signal.h>' > a.c
2. gcc -c a.c
Compiler error message
does not happen on Opteron or x86 with the same software versions
I don't see any problems (glibc-devel-2.3.2-77, glibc-kernheaders-2.4-8.31).
As for mixing <asm/signal.h> (or <linux/signal.h>) and <signal.h>, you really
cannot do that, they are mutually exclusive.
Can you attach
echo '#include <signal.h>' | gcc -E -dD -xc -
output so that I can see where exactly the problem on your box comes from?
Oops ? Sorry, sorry, sorry.
The a.c compilation works now unlike a few days ago.
There were several RPM updates in the meantime,
among others glibc-kernheaders.
The other problem is gone, too, i was able to
build the PAM RPM from source, what was impossible
a few days ago.
Anyway thanks a lot for the respons and sorry for
the superfluous effort.
Closing as resolved now.