Bug 103255 - signal related headers inconsistent, strange defines lead to problems on Itanium systems
Summary: signal related headers inconsistent, strange defines lead to problems on Itan...
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: glibc
Version: 3.0
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact: Brian Brock
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2003-08-28 07:34 UTC by Albert Fluegel
Modified: 2007-11-30 22:06 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2003-08-28 16:02:30 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Albert Fluegel 2003-08-28 07:34:18 UTC
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,
                  from a.c:1:
/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:
enum
{
  1 = 1,

  2

};
leading to barfing. in my opinion the enum for ss_flags is
superfluous.

Version-Release number of selected component (if applicable):
glibc-2.3.2-69 through glibc-2.3.2-77

How reproducible:


Steps to Reproduce:
1. echo '#include <signal.h>' > a.c
2. gcc -c a.c
3.
    
Actual results:
Compiler error message


Expected results:
a.o created

Additional info:
does not happen on Opteron or x86 with the same software versions

Comment 1 Jakub Jelinek 2003-08-28 12:08:56 UTC
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?

Comment 2 Albert Fluegel 2003-08-28 15:36:00 UTC
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.


Comment 3 Bill Nottingham 2003-08-28 16:02:30 UTC
Closing as resolved now.


Note You need to log in before you can comment on or make changes to this bug.