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)
Tracking
(Not tracked)
RESOLVED
FIXED
mozilla1.4alpha
People
(Reporter: gl, Assigned: dbaron)
References
Details
(Whiteboard: [patch])
Attachments
(3 files, 2 obsolete files)
1.06 KB,
patch
|
bryner
:
superreview+
|
Details | Diff | Splinter Review |
998 bytes,
patch
|
Details | Diff | Splinter Review | |
1.93 KB,
patch
|
bryner
:
review+
dmosedale
:
superreview+
|
Details | Diff | Splinter Review |
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);
Reporter | ||
Comment 1•22 years ago
|
||
*** Bug 177913 has been marked as a duplicate of this bug. ***
Reporter | ||
Comment 2•22 years ago
|
||
*** Bug 177914 has been marked as a duplicate of this bug. ***
Comment 3•22 years ago
|
||
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
Assignee | ||
Comment 4•22 years ago
|
||
Does this also work? It worked for me before (with RH 8.0, gcc 3.2), and this
works for me too.
Assignee | ||
Comment 5•22 years ago
|
||
Taking.
Assignee: sgehani → dbaron
Priority: -- → P3
Whiteboard: [patch]
Target Milestone: --- → mozilla1.3alpha
Comment 6•22 years ago
|
||
Patch fixed the problem for me.
Marking NEW
Status: UNCONFIRMED → NEW
Ever confirmed: true
Assignee | ||
Updated•22 years ago
|
Attachment #104889 -
Flags: superreview?(bryner)
Reporter | ||
Comment 7•22 years ago
|
||
Patch works for me.
Comment 8•22 years ago
|
||
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+
Assignee | ||
Comment 9•22 years ago
|
||
Patch checked in to trunk, 2003-01-17 15:44 PST.
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 10•22 years ago
|
||
Backed out, since it broke some RH 7.x configurations, and only one person has
ever seen this problem.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Assignee | ||
Updated•22 years ago
|
Status: REOPENED → ASSIGNED
Priority: P3 → P5
Whiteboard: [patch]
Target Milestone: mozilla1.3alpha → Future
Assignee | ||
Comment 11•22 years ago
|
||
<jrgm> dbaron: just FYI the comm. tinderbox I was looking at was RH7.1, gcc
2.96, 2.4.7-10smp
Comment 12•22 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.
Assignee | ||
Comment 13•22 years ago
|
||
Oh, glibc-2.3.1. That explains the difference, anyway.
Assignee | ||
Comment 14•22 years ago
|
||
Attachment #104889 -
Attachment is obsolete: true
Assignee | ||
Updated•22 years ago
|
Attachment #113686 -
Flags: superreview?(bryner)
Assignee | ||
Updated•22 years ago
|
Whiteboard: [patch]
Target Milestone: Future → mozilla1.4alpha
Comment 15•22 years ago
|
||
Peeking into the patch... May I politely propose using __GLIBC_PREREQ(2,3)? *grin*
Assignee | ||
Comment 16•22 years ago
|
||
I have a vague memory of some older versions of glibc not *having* GLIBC_PREREQ.
Comment 17•22 years ago
|
||
defined __GLIBC_PREREQ && __GLIBC_PREREQ(2,3) may help. At glibc-3.1 your test will fail.
Comment 18•22 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)
Assignee | ||
Comment 19•22 years ago
|
||
Right, I've gotten mad at other people for making that mistake. Oops.
Attachment #113686 -
Attachment is obsolete: true
Assignee | ||
Updated•22 years ago
|
Attachment #113686 -
Flags: superreview?(bryner)
Assignee | ||
Updated•22 years ago
|
Attachment #113717 -
Flags: superreview?(bryner)
Updated•22 years ago
|
Attachment #113717 -
Flags: superreview?(bryner) → superreview+
Comment 20•22 years ago
|
||
David, the patch is working. nsSigHandler was compiling without errors.
Reporter | ||
Comment 21•22 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.
Assignee | ||
Comment 22•22 years ago
|
||
The default glibc on RedHat 8 is 2.2.93, not 2.3.x
Reporter | ||
Comment 23•22 years ago
|
||
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
Comment 24•22 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.
Assignee | ||
Comment 25•22 years ago
|
||
It turns out that we can't used __GLIBC_PREREQ, since some compilers report a
parse error when it's not present.
Assignee | ||
Comment 26•22 years ago
|
||
Fix checked in to trunk, 2003-02-22 11:22 PST/12:45 PST.
Status: ASSIGNED → RESOLVED
Closed: 22 years ago → 22 years ago
Resolution: --- → FIXED
Comment 27•22 years ago
|
||
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?
Assignee | ||
Comment 28•22 years ago
|
||
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•22 years ago
|
||
David, my compilation is just finished with nsSigHandlers.cpp revision 1.34 so
everything seems to be OK.
Comment 30•22 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?
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Comment 31•22 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•22 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=\"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.
Comment 33•22 years ago
|
||
and Debian unstable is glibc 2.3.1, btw.
Comment 34•22 years ago
|
||
/usr/include/features.h:
#ifdef _GNU_SOURCE
# define __USE_GNU 1
#endif
Comment 35•22 years ago
|
||
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 36•22 years ago
|
||
Assignee | ||
Comment 37•22 years ago
|
||
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).
Assignee | ||
Comment 38•22 years ago
|
||
*** Bug 207459 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 39•22 years ago
|
||
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.
Assignee | ||
Updated•22 years ago
|
Attachment #124473 -
Flags: review?(bryner)
Updated•22 years ago
|
Attachment #124473 -
Flags: review?(bryner) → review+
Assignee | ||
Updated•22 years ago
|
Attachment #124473 -
Flags: superreview?(dmose)
Comment 40•22 years ago
|
||
Comment on attachment 124473 [details] [diff] [review]
patch to remove use of strsignal
sr=dmose@mozilla.org
Attachment #124473 -
Flags: superreview?(dmose) → superreview+
Assignee | ||
Comment 41•22 years ago
|
||
Fix checked in to trunk, 2003-06-01 13:18 PDT.
Status: REOPENED → RESOLVED
Closed: 22 years ago → 22 years ago
Resolution: --- → FIXED
Updated•20 years ago
|
Product: Core → Mozilla Application Suite
You need to log in
before you can comment on or make changes to this bug.
Description
•