Closed Bug 177912 Opened 22 years ago Closed 21 years ago

Problem compiling nsSigHandlers.cpp, gcc 3.2, RH 8.0


(SeaMonkey :: UI Design, defect, P5)



(Not tracked)



(Reporter: gl, Assigned: dbaron)



(Whiteboard: [patch])


(3 files, 2 obsolete files)

I get an error when compiling with  gcc 3.2 under RH 8.0

In file included from ../../dist/include/xpcom/nsID.h:41,
                 from ../../dist/include/xpcom/nsISupportsBase.h:44,
                 from ../../dist/include/xpcom/nsISupportsUtils.h:49,
                 from nsSigHandlers.cpp:116:
/usr/include/string.h:319: declaration of `char* strsignal(int) throw ()'
   throws different exceptions
nsSigHandlers.cpp:71: than previous declaration `char* strsignal(int)'
make[3]: *** [nsSigHandlers.o] Error 1
make[3]: Leaving directory `/home/gl/mozilla/xpfe/bootstrap'
make[2]: *** [tier_99] Error 2
make[2]: Leaving directory `/home/gl/mozilla'
make[1]: *** [default] Error 2
make[1]: Leaving directory `/home/gl/mozilla'
make: *** [build] Error 2

To workaround I commented out the following line in nsSigHandlers.cpp 
but that isnt the real solution
//extern "C" char * strsignal(int);
*** Bug 177913 has been marked as a duplicate of this bug. ***
*** Bug 177914 has been marked as a duplicate of this bug. ***
I don't know why we aren't just including <string.h> there.  Anyway, over to XP

Assignee: seawood → sgehani
Component: Build Config → XP Apps
QA Contact: granrose → paw
Summary: Problem compiling nsSigHandlers.cpp, gcc 3.2, RH 8.0 → Problem compiling nsSigHandlers.cpp, gcc 3.2, RH 8.0
Attached patch possible patch (obsolete) — Splinter Review
Does this also work?  It worked for me before (with RH 8.0, gcc 3.2), and this
works for me too.
Assignee: sgehani → dbaron
Priority: -- → P3
Whiteboard: [patch]
Target Milestone: --- → mozilla1.3alpha
Patch fixed the problem for me.

Marking NEW
Ever confirmed: true
Patch works for me.
Comment on attachment 104889 [details] [diff] [review]
possible patch

sr=bryner (i _hate_ these feature-set conditional prototypes on linux)
Attachment #104889 - Flags: superreview?(bryner) → superreview+
Patch checked in to trunk, 2003-01-17 15:44 PST.
Closed: 22 years ago
Resolution: --- → FIXED
Backed out, since it broke some RH 7.x configurations, and only one person has
ever seen this problem.
Resolution: FIXED → ---
Priority: P3 → P5
Whiteboard: [patch]
Target Milestone: mozilla1.3alpha → Future
<jrgm> dbaron: just FYI the comm. tinderbox I was looking at was RH7.1, gcc
2.96, 2.4.7-10smp
Confirming bug on a Linux From Scratch, gcc-3.2, glibc-2.3.1

I was building Mozilla daily but this bug showed up just yesterday when I
reconfigured with --enable-debug.
Oh, glibc-2.3.1.  That explains the difference, anyway.
Attached patch proposed patch (obsolete) — Splinter Review
Attachment #104889 - Attachment is obsolete: true
Whiteboard: [patch]
Target Milestone: Future → mozilla1.4alpha
Peeking into the patch...  May I politely propose using __GLIBC_PREREQ(2,3)?  *grin*
I have a vague memory of some older versions of glibc not *having* GLIBC_PREREQ.
defined __GLIBC_PREREQ && __GLIBC_PREREQ(2,3) may help.  At glibc-3.1 your test will fail.
David, the expression after if will fail at every version of glibc whith minor
version number 2 or less.  Also you automatically assume __GLIBC__ and
__GLIBC__MINOR__ is defined (libc5?).  Please, consider

#if defined __GLIBC_PREREQ && __GLIBC_PREREQ(2,3)
Attached patch patchSplinter Review
Right, I've gotten mad at other people for making that mistake.  Oops.
Attachment #113686 - Attachment is obsolete: true
Attachment #113717 - Flags: superreview?(bryner) → superreview+
David, the patch is working.  nsSigHandler was compiling without errors.
Patch works for me. Redhat 8.

I'm a bit surprised that there werent more people who ran into  the problem,
particularly as I would have thought RH8 is fairly widely used and that 
building Mozilla on that platform triggers it.

Maybe there's just not that many people building the browser ...

Anyway. Done. Thanks.
The default glibc on RedHat 8 is 2.2.93, not 2.3.x
Yes, default glibc on RH8 is 2.2.93, 

localhost% rpm -q glibc

but <features.h> reports it as 2.3

/* Major and minor version number of the GNU C library package.  Use
   these macros to test for features in specific releases.  */
#define __GLIBC__       2
#define __GLIBC_MINOR__ 3

I read that 2.2.93 was considered a preliminary 2.3
Well, there is an ultimate solution - the configure script should check for
strsignal symbol in libc and its prototype in the headers.  Just a thought.
It turns out that we can't used __GLIBC_PREREQ, since some compilers report a
parse error when it's not present.
Fix checked in to trunk, 2003-02-22 11:22 PST/12:45 PST.
Closed: 22 years ago22 years ago
Resolution: --- → FIXED
David, I think checking for strsignal() should be moved to

Is it right that all this magic is done because some older glibc's have this
function but do not have the prototype for it in the headers?
If I have to change this again in the future, I'll just remove the strsignal,
since we don't really need it.
David, my compilation is just finished with nsSigHandlers.cpp revision 1.34 so
everything seems to be OK.
Sorry, but this seems to be back: I can't build on debian sarge (testing).

nsSigHandlers.cpp: In function `void ah_crap_handler(int)':
nsSigHandlers.cpp:134: `strsignal' undeclared (first use this function)

In string.h, strsignal is only defined ifdef __USE_GNU.

If I change the define in nsSigHandlers.cpp to 
#if __GLIBC__ > 2 || (__GLIBC__ == 2 && __GLIBC_MINOR__ >= 3 && defined(__USE_GNU)) 
then it builds, but I have no idea whether this is the right solution.  Is
__USE_GNU defined on 2.3 platforms where the existing build works?
Resolution: FIXED → ---
Yup, confirmed. This time with:

diz $ g++-2.95 -v
Reading specs from /usr/lib/gcc-lib/i386-linux/2.95.4/specs
gcc version 2.95.4 20011002 (Debian prerelease)

on Debian unstable.

My man page suggests that strsignal() requires #define _GNU_SOURCE, which I
don't see in  nsSigHandlers.cpp.
My error was:

g++-2.95 -o nsSigHandlers.o -c -DXPCOM_GLUE -DOSTYPE=\"Linux2.4\" -DOSARCH=\"Lin
ux\" -DSPLASH_XPM=\"./splash.xpm\" -I. -I. -I../../dist/include/xpcom -I../../di
st/include/xpconnect -I../../dist/include/string -I../../dist/include/webbrwsr -
I../../dist/include/widget -I../../dist/include/dom -I../../dist/include/necko -
I../../dist/include/pref -I../../dist/include/appshell -I../../dist/include/gfx 
-I../../dist/include/chrome -I../../dist/include/xpinstall -I../../dist/include/
uriloader -I../../dist/include/view -I../../dist/include/windowwatcher -I../../d
ist/include/embed_base -I../../dist/include/embedcomponents -I../../dist/include
/browser -I../../dist/include/docshell -I../../dist/include/uconv -I../../dist/i
nclude/locale -I../../dist/include/xremoteservice -I../../dist/include/profile -
I../../dist/include/jprof -I../../dist/include/apprunner -I../../dist/include -I
/usr/local/src/mozilla/cvs/mozilla/dist/include/nspr      -I/usr/X11R6/include  
 -fPIC  -I/usr/X11R6/include -fno-rtti -fno-exceptions -Wall -Wconversion -Wpoin
ter-arith -Wcast-align -Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy -peda
ntic -Wno-long-long -pthread -pipe  -DDEBUG -D_DEBUG -DDEBUG_calum -DTRACING -g 
-fno-inline -DWIDGET_DLL=\"\" -DGFXWIN_DLL=\"\" -I/
usr/include/gtk-1.2 -I/usr/include/glib-1.2 -I/usr/lib/glib/include -I/usr/X11R6
/include  -I/usr/X11R6/include -DMOZILLA_CLIENT -include ../../mozilla-config.h 
-Wp,-MD,.deps/nsSigHandlers.pp nsSigHandlers.cpp
nsSigHandlers.cpp: In function `void ah_crap_handler(int)':
nsSigHandlers.cpp:133: `strsignal' undeclared (first use this function)
nsSigHandlers.cpp:133: (Each undeclared identifier is reported only once
nsSigHandlers.cpp:133: for each function it appears in.)

trying to build from a cvs checkout yesterday.
and Debian unstable is glibc 2.3.1, btw.

#ifdef  _GNU_SOURCE
# define __USE_GNU      1
This bug won't be seen if "--disable-debug" is used, since:

#if defined(LINUX) && defined(DEBUG) && (defined(__i386) || defined(PPC))




ah_crap_handler(int signum)


Comment on attachment 121041 [details] [diff] [review]
get strsignal from string.h

r=dbaron, assuming that this is cleanup from your removal of POSIX_SOURCE
and/or other similar defines, and assuming that you have reason to think it
will work now (see all the other failed patches above).
*** Bug 207459 has been marked as a duplicate of this bug. ***
strsignal just isn't that important.  People can do 'man 7 signal' if they
forget that 11 is SIGSEGV, or if they need one of the other numbers.  It's not
worth this much trouble.
Attachment #124473 - Flags: review?(bryner) → review+
Comment on attachment 124473 [details] [diff] [review]
patch to remove use of strsignal
Attachment #124473 - Flags: superreview?(dmose) → superreview+
Fix checked in to trunk, 2003-06-01 13:18 PDT.
Closed: 22 years ago21 years ago
Resolution: --- → FIXED
Product: Core → Mozilla Application Suite
You need to log in before you can comment on or make changes to this bug.