Closed Bug 177912 Opened 22 years ago Closed 22 years ago

Problem compiling nsSigHandlers.cpp, gcc 3.2, RH 8.0

Categories

(SeaMonkey :: UI Design, defect, P5)

x86
Linux
defect

Tracking

(Not tracked)

RESOLVED FIXED
mozilla1.4alpha

People

(Reporter: gl, Assigned: dbaron)

References

Details

(Whiteboard: [patch])

Attachments

(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 Apps.
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.
Taking.
Assignee: sgehani → dbaron
Priority: -- → P3
Whiteboard: [patch]
Target Milestone: --- → mozilla1.3alpha
Patch fixed the problem for me. Marking NEW
Status: UNCONFIRMED → 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.
Status: NEW → RESOLVED
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.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Status: REOPENED → ASSIGNED
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 glibc-2.2.93-5 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.
Status: ASSIGNED → RESOLVED
Closed: 22 years ago22 years ago
Resolution: --- → FIXED
David, I think checking for strsignal() should be moved to configure.in 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?
Status: RESOLVED → REOPENED
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=\"libwidget_gtk.so\" -DGFXWIN_DLL=\"libgfx_gtk.so\" -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.
/usr/include/features.h: #ifdef _GNU_SOURCE # define __USE_GNU 1 #endif
This bug won't be seen if "--disable-debug" is used, since: #if defined(LINUX) && defined(DEBUG) && (defined(__i386) || defined(PPC)) #define CRAWL_STACK_ON_SIGSEGV #endif ... #elif defined(CRAWL_STACK_ON_SIGSEGV) ... ah_crap_handler(int signum) ... strsignal(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 sr=dmose@mozilla.org
Attachment #124473 - Flags: superreview?(dmose) → superreview+
Fix checked in to trunk, 2003-06-01 13:18 PDT.
Status: REOPENED → RESOLVED
Closed: 22 years ago22 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.

Attachment

General

Created:
Updated:
Size: