143041 - -fshort-wchar no longer detected by configure

Status: VERIFIED DUPLICATE of bug 139211

(SeaMonkey :: Build Config, defect)

Description

[Bradley Baetz (:bbaetz)]

I just upgraded to RH7.3 from RH7.2 so I figured that I should clobber my
objdir, just in case there were any major compiler changes.

However, configure now gives:

checking for usable wchar_t (2 bytes, unsigned)... no
checking for compiler -fshort-wchar option... no

Looking in config.log, I get:

configure:6039: checking for usable wchar_t (2 bytes, unsigned)
configure:6054: gcc -o conftest    -I/usr/X11R6/include  conftest.c  -lc 1>&5
configure: failed program was:
#line 6047 "configure"
#include "confdefs.h"
#include <stdlib.h>
                 int main () {
                   return (sizeof(wchar_t) != 2) ||
                          (wchar_t)-1 < (wchar_t) 0 ; } 
configure:6089: checking for compiler -fshort-wchar option
configure:6107: c++ -o conftest  -fshort-wchar   -I/usr/X11R6/include 
conftest.C  -lc 1>&5
In file included from configure:6101:
/usr/include/stdlib.h:577: declaration of `void exit (int) throw ()' 
throws different exceptions
configure:6099: than previous declaration `void exit (int)'
configure: failed program was:
#line 6097 "configure"
#include "confdefs.h"
#ifdef __cplusplus
extern "C" void exit(int);
#endif
#include <stdlib.h>
                     int main () {
                       return (sizeof(wchar_t) != 2) ||
                              (wchar_t)-1 < (wchar_t) 0 ; } 


This is related to the fix for bug 139211, I presume.

rebuilding configure by running 'autoconf' in the source dir fixes this. |rpm -q
autoconf| gives autoconf-2.13-17.

The autoconf changelog includes:

* Wed Jun 27 2001 Jens Petersen <[e-mail]>

- Add a back-port of _AC_PROG_CXX_EXIT_DECLARATION
  from version 2.50 to make detection of C++ exit()
  declaration prototype platform independent.  The check is
  done in AC_PROG_CXX with the result stored in "confdefs.h".
  The exit() prototype in AC_TRY_RUN_NATIVE is no longer needed.
  (fixes #18829)

Did someone rebuild configure with an autoconf version without this? The last
configure checkin is:

revision 1.960
date: 2002/05/06 20:11:12;  author: leaf%mozilla.org;  state: Exp;  lines: +3 -3
Automated update

so I guess leaf's autoconf needs updating...

This is cached, so you wouldn't see it unless you clobbered (including removing
config.cache) since that checkin.

daa (in #mozilla) isn't seeing this, but its 100% reproducable for me. Running
autoconf causes configure to find -fshort-wchar, and cvs up -C configure causes
it to fail again.

Nothing else in configure seems to use AC_TRY_RUN with C++, so I don't think
anything else is affected.

Comment 1

[Bradley Baetz (:bbaetz)]

OK, further discussion with daa indicates that he is seeing this - he doesn't
have -fshort-wchar.

However, isn't bug 139211 totally wrong? -fshort-wchar is an ABI change. So if
we only set this for CXX_FLAGS, won't this mean that a prunichar* string passed
from c++ (eg mozilla) to c (eg nspr) will cause strange things to happen, as the
c version treats the 2-byte wchar_t's as 4-byte? Or is PRUnichar only used in c++?

OTOH, we have this little gem in nscore.h:

#ifndef __PRUNICHAR__
#define __PRUNICHAR__
  /* For now, don't use wchar_t on Unix because it breaks the Netscape
   * commercial build.  When this is fixed there will be no need for the
   * |NS_REINTERPRET_CAST| in nsLiteralString.h either.
   */
  #if defined(HAVE_CPP_2BYTE_WCHAR_T) && (defined(NS_WIN32) || defined(XP_MAC))
    typedef wchar_t PRUnichar;
  #else
    typedef PRUint16 PRUnichar;
  #endif
#endif

which sort of implies that we aren't using wchar_t anyway on unix, except in the
L"foo" stuff for literal strings. Is that true?

Comment 2

[david avery]

the diff between a autoconf'd configure and cvs is :

diff configure configure.sav | more

6099c6099
< extern "C" void exit(int);
---
> extern "C" void exit(int) throw();
8725c8725
< extern "C" void exit(int);
---
> extern "C" void exit(int) throw();
12032c12032
< extern "C" void exit(int);
---
> extern "C" void exit(int) throw();

the affected tests are :

echo "configure:6089: checking for compiler -fshort-wchar option" >&5  
echo $ac_n "checking for C++ dynamic_cast to void*""... $ac_c" 1>&6             
echo "configure:12025: checking whether C++ compiler has -pedantic long long
bug" >&5

Comment 3

[Bradley Baetz (:bbaetz)]

My configure diff is bigger - |cvs diff configure | wc -l| gives 3812 lines.
Lots of that is line number changes, mind you. I don't even have the exit
protype in there - see the changelog entry. You have RH7.1, you mentioned?

So the fix is to update leaf's script's autoconf version, check in the new
version, and then get everyone to delete their config.cache so that things will
be rebuilt using -fshort-wchar if appropriate.

Comment 4

[hacker formerly known as [e-mail]]

I'm immediately suspect of any of RH's autoconf 2.50 backports as they caused
problems before, bug 134363 &
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=62361 .  Upgrading to RH
7's version of autoconf is *not* a proper solution at this time, especially
since all of our build boxes are still RH6.x.

From http://bugzilla.mozilla.org/show_bug.cgi?id=139211#c6 , 
"We should be OK using it only for C++, since PRUnichar is never actually
typedef-ed to wchar_t on Unix." -dbaron

I really don't care either way.  We can disable -fshort-char altogether if CC
doesn't support it.

Comment 5

[hacker formerly known as [e-mail]]

And we don't need 2 bug discussing the same issue. Duping.

*** This bug has been marked as a duplicate of 139211 ***

Comment 6

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

Regarding comment 1, see nsLiteralString.h (and the NS_REINTERPRET_CAST usage).

Comment 7

[Bradley Baetz (:bbaetz)]

Err. This isn't a dupe. This was _caused_ by the patch in bug 139211 being
checked in, and I'm proposing to back this change out.

Was the person who had the -fshort-wchar option accepted only in c++, and not c,
running the same release of gcc/g++ ? That just seems odd.

Comment 8

[hacker formerly known as [e-mail]]

It's a dupe in the sense that it's the same issue being discussed and the
original bug on the problem is still open.  There's no point in keeping a
separate bug open.  There was no indication that the versions of gcc/g++  being
used were different.  


*** This bug has been marked as a duplicate of 139211 ***

Comment 9

[Jon Granrose]

verified dup.