Problem compiling nsSigHandlers.cpp, gcc 3.2, RH 8.0

RESOLVED FIXED in mozilla1.4alpha


16 years ago
14 years ago


(Reporter: gl, Assigned: dbaron)



Firefox Tracking Flags

(Not tracked)


(Whiteboard: [patch])


(3 attachments, 2 obsolete attachments)



16 years ago
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);

Comment 1

16 years ago
*** Bug 177913 has been marked as a duplicate of this bug. ***

Comment 2

16 years ago
*** 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
Created attachment 104889 [details] [diff] [review]
possible patch

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

Comment 6

16 years ago
Patch fixed the problem for me.

Marking NEW
Ever confirmed: true
Attachment #104889 - Flags: superreview?(bryner)

Comment 7

16 years ago
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.
Last Resolved: 16 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

Comment 12

16 years ago
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.
Created attachment 113686 [details] [diff] [review]
proposed patch
Attachment #104889 - Attachment is obsolete: true
Attachment #113686 - Flags: superreview?(bryner)
Whiteboard: [patch]
Target Milestone: Future → mozilla1.4alpha

Comment 15

16 years ago
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.

Comment 17

16 years ago
defined __GLIBC_PREREQ && __GLIBC_PREREQ(2,3) may help.  At glibc-3.1 your test will fail.

Comment 18

16 years ago
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)
Created attachment 113717 [details] [diff] [review]

Right, I've gotten mad at other people for making that mistake.  Oops.
Attachment #113686 - Attachment is obsolete: true
Attachment #113686 - Flags: superreview?(bryner)
Attachment #113717 - Flags: superreview?(bryner)
Attachment #113717 - Flags: superreview?(bryner) → superreview+

Comment 20

16 years ago
David, the patch is working.  nsSigHandler was compiling without errors.

Comment 21

16 years ago
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

Comment 23

16 years ago
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

Comment 24

16 years ago
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.
Last Resolved: 16 years ago16 years ago
Resolution: --- → FIXED

Comment 27

16 years ago
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.

Comment 29

16 years ago
David, my compilation is just finished with nsSigHandlers.cpp revision 1.34 so
everything seems to be OK.

Comment 30

16 years ago
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 → ---

Comment 31

16 years ago
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.

Comment 32

16 years ago
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.

Comment 33

16 years ago
and Debian unstable is glibc 2.3.1, btw.

Comment 34

16 years ago

#ifdef  _GNU_SOURCE
# define __USE_GNU      1

Comment 35

16 years ago
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. ***
Created attachment 124473 [details] [diff] [review]
patch to remove use of strsignal

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)
Attachment #124473 - Flags: review?(bryner) → review+
Attachment #124473 - Flags: superreview?(dmose)
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.
Last Resolved: 16 years ago16 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.