63604 - mozilla does not build with gcc-3.0

Status: VERIFIED FIXED

(SeaMonkey :: Build Config, defect, P5)

Description

[Chris Waterson]

I spent an hour or so trying to make this build the other day. It looks like the 
primary problem is missing `compatibility headers'; e.g., there is no `new.h', 
only `new'.

scc, you're the C++ porting bi^H^H expert, so I'm gonna give this hunk o' 
burning love to you. Basically, I think you'll need to work up some autoconf 
tests that check for the existence of some of the standard header files (e.g., 
HAVE_NEW_H and/or NEED_NEW_H) and #ifdef the includers properly. cc'ing cls, who 
can probably help you in the endeavor.

Comment 1

[Chris Waterson]

Idiot's guide to building `the latest' gcc.

% cd /usr/src
% su
password: [whatever]
# mkdir gcc
# chmod go+wx gcc [so normal humans can write to it]
# exit
% cd gcc
% cvs -d :pserver:[e-mail]:/cvs/gcc login
password: [no password; just hit return]
% cvs -d :pserver:[e-mail]:/cvs/gcc checkout gcc
[this pulls /usr/src/gcc/gcc]
% mkdir build [under /usr/src/gcc]
% cd build [now you're in /usr/src/gcc/build]
% ../gcc/configure --prefix=/usr/local/gcc-trunk --enable-languages=c++
[spew]
% make bootstrap
[spew]
% su
password: [whatever]
[assuming cwd still is /usr/src/gcc/build]
# mkdir /usr/local/gcc-trunk
# make install
# exit
[now we'll make it so that the new compiler is the one we'll use by default]
% setenv PATH /usr/local/gcc-trunk/bin:${PATH}
% setenv LD_LIBRARY_PATH /usr/local/gcc-trunk/lib:${PATH}
% which gcc
/usr/local/gcc-trunk/bin/gcc
% cd /tmp
% cat > foo.cpp
int main(int argc, char* argv[]) { return 0; }
^D
% c++ foo.cpp
[that should work]
% ./a.out
[that should work]

Now you are ready to rock & roll.

Comment 2

[Chris Waterson]

Oops, the password for anoncvs is `anoncvs'.

Comment 3

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

Are the gcc folks really planning to break this?  I'd think we're not the only
ones who depend on it.

Comment 4

[Chris Waterson]

I've posted queries to [e-mail] and [e-mail].

Comment 5

[Chris Waterson]

Hmm; dug a little deeper and it looks like they might be included under the 
`backward' subdirectory. Maybe all we need to do is add a `-Ibackward' 
somwhere...

Comment 6

[Chris Waterson]

Sho'nuf...

Subject: Re: libstdc++-v3 `compatibility' headers?
   Date: Fri, 22 Dec 2000 12:08:33 -0800 (PST)
   From: Benjamin Kosnik <[e-mail]>
     To: Chris Waterson <[e-mail]>
     CC: [e-mail], [e-mail]

that battle is currently raging on the [e-mail] list.

The answer is yes, where they will be located in the installed directory 
is currently under debate. See 'backward + [v3]' searches on gcc-patches 
or libstdc++ lists.

In the source directory they are in include/backward

best,
benjamin

On Fri, 22 Dec 2000, Chris Waterson wrote:

> Are there plans to include `compatibility headers' (e.g., `new.h' as
> well as `new') with libstdc++-v3?

Comment 7

[Jonathan Lennox]

Maybe this is provocative, but even if backward-compatibility headers are
available, wouldn't having Mozilla be buildable using the standard ISO C++
library be a good idea?  (I imagine this will mean having autoconf stick 'using
namespace std;' in some universally-included header file, at this point.)

Also, XPCOM hackers probably need to be aware that the G++ V3 ABI has changed
the vtable layout again (for the last time, they promise).

Comment 8

[jim_nance]

The new.h problem seems to be gone.  The latest problem that I am having has to
do with istream and ostream.  The g++ headers typedef istream and ostream to
something.  Unfortunatly in a couple of files we have forward declarations like:

class istream

g++ gets mad that istream is a typedef and not a real class.  I dont know if it
should be mad about this (SCC?).  Does anyone have a good suggestion for fixing
this?

Also it seems that g++ does not like the hex in the statement:
    cerr << hex << err << dec;

I am going to attach a patch that allows me to get mozilla to build around these
problems.  Its not a fix because it will break other platforms, but it does
let you find the next problem.

Comment 9

[jim_nance]

Attachment: quick had for gcc 3.0

Comment 10

[cls]

Sorry about the spam. An unset priority should be less than P5.  

Comment 11

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

hex and dec seem to now be ios_base::hex and ios_base::dec.  Based on C++
27.4.2.1.2 and especially 27.4.2 this seems right, although I'm not sure.
This doesn't seem at first glance like a backwards-compatible change.  Old
gcc headers have ios::hex and ios::dec (and obviously also have hex and dec
somewhere).


Based on C++ 27.6 which gives:

typedef basic_istream<char> istream;

the latter seems like it may also be a legitimate problem in Mozilla, since I
think section 7.1.3, clause 3, which says:

  In a given scope, a |typedef| specifier shall not be used to redefine the
  name of any type declared in that scope to refer to a different type.  

applies to forward declarations since section 9.1, clause 2, says:

  A declaration consisting solely of _class-key-identifier_ ; is either a
  redeclaration of the name in the current scope or a forward declaration
  of the identifier as a class name.  It introduces the class name into
  the current scope.

Comment 12

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

Actually, using |ios::hex| and |ios::dec| fixes the problem, but not
ios_base::... (since there's no |using std::ios_base| in iostream.h).
Are those portable?  (A search for "ios::" in LXR does turn up some
hits, but not hex.)  The C++ standard doesn't seem to require them to
be globally defined, although perhaps there need to be some more
|using| declarations in iostream.h for backwards compatibility...

I really can't see how it worked in the old gcc -- maybe there was a bug
that caused enums within classes to show up globally?

I'm also hitting some bugs in the header files that cause them not to work
with exceptions disabled...

Comment 13

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

Well, I managed to get a completed build on the current (yesterday, I think) gcc
trunk.  I'll attach the patch that I used.  I also needed to modify two system
headers (localefwd.h and basic_ios.h) to build with -fno-exceptions.

The build doesn't run, and TestXPTCInvoke fails:

calling direct:
	1 + 1 = 2
	1L + 1L = 2
	2 * 2 = 4
	2L * 2L = 4
	1 + 2 + 3 + 4 + 5 + 6 + 7 + 8 + 9 + 10 = 55.000000
	1 + 2 + 3 + 4 + 5 + 6 + 7 + 8 + 9 + 10 = 55.000000f
calling via invoke:
	1 + 1 = 0
	1L + 1L = 0
./run-mozilla.sh: line 72:  3045 Segmentation fault      $prog ${1+"$@"}

I saw something somewhere about ABI changes.  See, e.g.:
http://gcc.gnu.org/ml/gcc-patches/2000-11/msg00937.html
http://gcc.gnu.org/ml/gcc-patches/2000-11/msg00198.html
Would these symptoms be the expected result?  How much work does this require us
to do?

Comment 14

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

Attachment: changes to Mozilla that I needed to build on "gcc version 2.97 20010208 (experimental)"

Comment 15

[Jonathan Lennox]

Yes, that's the normal result of xptcall being wrong for your C++ ABI.  (I've
seen it a lot because FreeBSD uses two different C++ ABIs depending on which
version of the compiler you're using.)

<http://www.mozilla.org/scriptable/xptcall-faq.html> has information on how you
port xptcall to a new ABI.  Since the xptcall porting status page says that Mike
Shaver is the person to talk to for Unix ports, I've added him as a Cc: on this
bug.

<http://reality.sgi.com/dehnert_engr/cxx/cxx-summary.html> has information on
the ia64 C++ ABI, which is also (cross-platform) the G++ V3 ABI.

Should we open a new bug (in the XPCOM category) for XPTCall support for the G++
V3 ABI?

Comment 16

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

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

Comment 17

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

The current gcc trunk now calls itself 3.1, and there's a branch with tag
"gcc-3_0-branch".

Comment 18

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

I filed http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view&pr=2079 on the
need for more |using| declarations in <iostream.h>, which will fix all
but one of the problems preventing us from compiling on gcc-3_0-branch
as of 2001-02-22.  (And I actually haven't tested the problem for which
I attached the patch to configure.in -- I should test to see if that
can be removed.  If it can't, we should figure out whether it should be
fixed in Mozilla, in libstdc++, or both.)

Comment 19

[cls]

My gcc 3.0-branch build failed on the domainname problem (and the hex/dec
problem) when I didn't have your patch (attach 24939).  I also tested the
changes on win32 and they work there as well.

Comment 20

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

I filed http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view&pr=2082 about g++
defining _GNU_SOURCE by default now, which causes header files to be different
when compiled as C++ rather than C.

However, I think this is a bug that should be fixed at both ends.  If we're
going to use the result of an autoconf test only in C++, we may as well do
the test in C++.  So does anybody want to review the configure.in patch in
attachment 24939 [details] [diff] [review] (ignoring the other changes)?  (Or do you think we shouldn't
yield to header files that differ between C and C++ compilers?)

Comment 21

[jim_nance]

The problem with dec and hex go away if iomanip.h is included.  Attaching
a patch.

Comment 22

[jim_nance]

Attachment: patch to add iomanip to needed files

Comment 23

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

Yeah, I filed a bug and they added the necessary using declarations to iomanip.h.
It still seems like bad backwards-compatibility.  (Does iomanip.h exist on all
distributions?)

Comment 24

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

Attachment: patch to build and run on gcc3

Comment 25

[cls]

r=cls on the configure.in tests and the HAVE_IOMANIP_H ifdefs

Comment 26

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

Attachment: same thing assuming that iomanip.h always exists (which may well be true)

Comment 27

[cls]

r=cls again.  (Let's see how many we can pile up. :)

Comment 28

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

In my tree, I changed the #ifdefs in the last part of the above patch to

+#if defined(__GXX_ABI_VERSION) && _GXX_ABI_VERSION >= 100 /* G++ V3 ABI */
+    "leal  (%%edx,%%eax,4), %%edx\n\t"
+#else /* not G++ V3 ABI  */
     "leal  8(%%edx,%%eax,4), %%edx\n\t"
+#endif /* G++ V3 ABI */

since that seems to be how the g++ maintainers #ifdef their tests that relate to
the new ABI.  It's not worth another attachment...

Comment 29

[Mike Shaver (:shaver emeritus)]

Dude, I like it. sr=shaver, and thanks.

(Reminds me that I've got some netbsd patches to check in, too.)

Comment 30

[John Bandhauer]

r=jband on dbaron's change.

Comment 31

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

Patches checked in.  We should now build an run on gcc3 on x86.  Filed
bug 71627 on xptcall changes needed for running on non-x86 with gcc3.

Comment 32

[Jon Granrose]

I see the checkins but don't have an x86 gcc 3.0 system to build on.  can
someone verify this is working now?

Comment 33

[Kevin Buhr]

G++ 3.0 normal builds work okay, but "--enable-optimize" builds crash on startup...

I built the MOZILLA_0_8_1_BRANCH pulled as of March 21 22:44 CST on an i386
Linux machine using the GCC "gcc-3_0-branch" CVS branch pulled as of March 20
19:48 CST.

I built three versions, with the following configure lines:

        ./configure
        ./configure --disable-tests --disable-debug --enable-optimize
        ./configure --disable-tests --disable-debug --enable-optimize=-O2

and I also built NSS and the PSM module with analogous configuration options.

All builds ran to completion without errors.

The non-optimized build appeared to create a working browser.  I haven't done
extensive testing on it, but I checked that the first ten pages in
Debug->Verification as well as connecting to a secure site worked fine.

On the other hand, both optimized browsers die on startup:

[ . . . ]
      MOZ_TOOLKIT=
        moz_debug=0
     moz_debugger=
**************************************************
nsNativeComponentLoader:
SelfRegisterDll(/disk/hda9/home/buhr/src/mozilla/build/mozilla_0_8_1/20010321/distribution/dist/bin/components/libnecko.so)
Load FAILED with error:
/disk/hda9/home/buhr/src/mozilla/build/mozilla_0_8_1/20010321/distribution/dist/bin/components/libnecko.so:
unexpected reloc type 0x20
**************************************************
[...]/run-mozilla.sh: line 72:  2965 Segmentation fault      $prog ${1+"$@"}

I haven't looked into the problem yet.

Comment 34

[cls]

Granrose, the changes work for me.  I've been using a gcc-3.0-branch based build
for the past week.  My latest tip builds were done with a gcc-3.0-branch build
from the night of 20010321.

Marking verified.

Buhr, file a separate bug on the problem you are seeing and provide some more
info, like OS version, libc version, etc.

Comment 35

[Kevin Buhr]

I tracked down the problem to a stale "/usr/local/lib/libz.a" (oops!).  For some
reason, linking against it occasionally corrupted the relocation records of the
resulting ELF shared object.  GCC 3.0 w/o debugging tickled the bug, though I
don't know why other configurations didn't.  Sorry for the false alarm.