139211 - Configure check for -fshort-wchar is broken

Status: RESOLVED FIXED

(SeaMonkey :: Build Config, defect, P3)

Description

[Andreas Oesterhelt]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0rc1) Gecko/20020417
BuildID:    2002041711

In configure.in, lines 1530ff there is what looks
as if someone had the idea to check for support of
the option -fshort-wchar in gcc, used the test above
as a cut&paste source, and then forgot to make changes.

With gcc 2.95.2, configure then incorrectly assumes that
-fshort-wchar is supoorted, which causes subsequent
AC_TRY_RUNs to fail.


Reproducible: Always
Steps to Reproduce:
1. Use gcc without support for -fshort-wchar
2. ./configure


Actual Results:  [...]
checking for compiler -fshort-wchar option... (cached) yes
[...]
checking for X11/extensions/XIElib.h... (cached) yes
configure: error: Could not compile basic X program.

Comment 1

[Andreas Oesterhelt]

Ooops, forget the cut&paste comment; I didn't
look right. The bug itself is valid, though.

Comment 2

[hacker formerly known as [e-mail]]

I build with gcc 2.95.3 all the time and it doesn't improperly detect
-fshort-wchar support.  

> checking for compiler -fshort-wchar option... (cached) yes
                                                ^^^^^^^^

Did you make sure that you did a 'make distclean' before changing compilers? 
Can you attach the full configure output & config.log when running configure on
a clean tree?

Comment 3

[Andreas Oesterhelt]

Attachment: configure output, called after make distclean

Comment 4

[Andreas Oesterhelt]

Attachment: Config log from clean tree as requested

Comment 5

[hacker formerly known as [e-mail]]

Hrm.  So, it looks as though -fshort-wchar is a valid flag for SuSE 7.1 (per
private email)'s g++ but not for gcc.  dbaron, would we run into any problems if
we used -fshort-wchar for c++ but not c? Should we add a test for $CC and fail
the general check if either test fails?

Comment 6

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

We should be OK using it only for C++, since PRUnichar is never actually
typedef-ed to wchar_t on Unix.  But you should add a comment mentioning that
hack in nscore.h (but I don't think it's worth changing nscore.h to add a
pointer back).

Comment 7

[hacker formerly known as [e-mail]]

Attachment: Only add -fshort-wchar to CXXFLAGS

Contains brief note about nscore.h as well.

Comment 8

[Brian Ryner (not reading)]

Comment on attachment 80699 [details] [diff] [review]
Only add -fshort-wchar to CXXFLAGS

r=bryner

Comment 9

[hacker formerly known as [e-mail]]

*** Bug 143041 has been marked as a duplicate of this bug. ***

Comment 10

[hacker formerly known as [e-mail]]

*** Bug 143041 has been marked as a duplicate of this bug. ***

Comment 11

[cls]

Attachment: Include stddef.h instead of stdlib.h to avoid exit() signature issues

According to bbaetz, the standard says that wchar_t should be declared in
stddef.h so just include it directly instead of going thru stdlib.h.

Comment 12

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Comment on attachment 83004 [details] [diff] [review]
Include stddef.h instead of stdlib.h to avoid exit() signature issues

r=dbaron

Comment 13

[hacker formerly known as [e-mail]]

http://mpt.phrasewise.com/2002/06/07

Comment 14

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Comment on attachment 83004 [details] [diff] [review]
Include stddef.h instead of stdlib.h to avoid exit() signature issues

Please land this on the 1.0.1 branch.  Once there, replace the
"mozilla1.0.1+" keyword with the "fixed1.0.1" keyword.