Cross-Compiling gcc 4 on Haiku broken

[bonefish]

Tested with a gcc 4.4.4 only Haiku, hrev42291, trying to build gcc 4 cross-compiler from hrev42433 sources (both Haiku and buildtools) using Haiku's configure script and --build-cross-tools-gcc4 x86 ....

gcc's configure script deduces from comparing host and target platform that it is building a native (not a cross-) compiler and errors out, complaining that --with-headers is supported for several targets.

Attaching patches intended to remedy the situation by introducing a gcc configure option --enable-cross-compiler and using it in Haiku's build/scripts/build_cross_tools_gcc4 script (the patches might not be sufficient -- I don't have a good overview of all the components of the gcc build system). After applying the gcc patch, autoconf needs to be run to update configure script. It only works when the inclusion of config/override.m4 in line 23 is commented out -- that file contains work-arounds for older autoconf versions which apparently break with a new one (yeah!).

With the patches applied the build goes further, but fails eventually with:

/Transfer/haiku-trunk/generated-gcc4-cross/cross-tools-build/gcc/./prev-gcc/xgcc -B/Transfer/haiku-trunk/generated-gcc4-cross/cross-tools-build/gcc/./prev-gcc/ -B/Transfer/haiku-trunk/generated-gcc4-cross/cross-tools/i586-pc-haiku/bin/ -c  -g -O2 -fomit-frame-pointer -DIN_GCC   -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wcast-qual -Wold-style-definition -Wc++-compat -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings   -DHAVE_CONFIG_H -I. -Icp -I/Transfer/buildtools/gcc/gcc -I/Transfer/buildtools/gcc/gcc/cp -I/Transfer/buildtools/gcc/gcc/../include -I/Transfer/buildtools/gcc/gcc/../libcpp/include -I/Transfer/haiku-trunk/generated-gcc4-cross/cross-tools-build/gcc/./gmp -I/Transfer/buildtools/gcc/gmp -I/Transfer/haiku-trunk/generated-gcc4-cross/cross-tools-build/gcc/./mpfr -I/Transfer/buildtools/gcc/mpfr  -I/Transfer/buildtools/gcc/gcc/../libdecnumber -I/Transfer/buildtools/gcc/gcc/../libdecnumber/dpd -I../libdecnumber    /Transfer/buildtools/gcc/gcc/cp/call.c -o cp/call.o
[...]
/Transfer/buildtools/gcc/gcc/cp/call.c: In function 'build_operator_new_call':
/Transfer/buildtools/gcc/gcc/cp/call.c:3101: internal compiler error: in gss_for_code, at gimple.c:131
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
make[3]: *** [cp/call.o] Error 1
make[3]: *** Waiting for unfinished jobs....
rm gcc.pod gcov.pod
make[3]: Leaving directory `/Transfer/haiku-trunk/generated-gcc4-cross/cross-tools-build/gcc/gcc'
make[2]: *** [all-stage2-gcc] Error 2
make[2]: Leaving directory `/Transfer/haiku-trunk/generated-gcc4-cross/cross-tools-build/gcc'
make[1]: *** [stage2-bubble] Error 2
make[1]: Leaving directory `/Transfer/haiku-trunk/generated-gcc4-cross/cross-tools-build/gcc'
make: *** [all] Error 2

After the "Waiting for unfinished jobs...." a gcc process remained that did not exit, consuming CPU time.

[bonefish]

Patch for buildtools introducing --enable-cross-compiler gcc 4 configure option

[bonefish]

Patch for build/scripts/build_cross_tools_gcc4 using the --enable-cross-compiler option

[modeenf]

I also have this problem :)

[mmlr]

FWIW the usual way was to build a native compiler and install that somewhere and use --cross-tools-prefix to specify its location. Installing the newer optional package alongside the existing 4.4.4 and using the same configure switch should work as well.

[bonefish]

The problem with this approach is that the target glue code and libraries that gcc builds will be built using the wrong headers (the build platform's instead of the target's).

[Disreali]

Any progress? Is this issue just that our gcc4 pkg is broken or is it something else?

[bonefish]

Replying to Disreali:

Any progress?

Nope.

Is this issue just that our gcc4 pkg is broken or is it something else?

The cause of the "internal compiler error" is unknown to me. It is encountered by the built xgcc, so it can have several possible causes:

• Our gcc 4.4.4 is broken/buggy, resulting in a broken xgcc.
• The gcc 4.5.x sources (the Haiku patched ones or already the original ones) are buggy, resulting in a broken xgcc.
• gcc 4.4.4 and the gcc 4.5.x sources are fine, but Haiku has a bug which results in a buggy xgcc.
• xgcc is fine, but Haiku has a bug which causes the error.

The best thing to do would be to finally complete, clean up, and upstream our Haiku gcc 4.* patches and ask the gcc folks how this kind of cross-building is supposed to work.

[leavengood]

Relating to the original ticket and the one I just logged: maybe Haiku should always be built using the libstdc++.so from the current GCC directory, even if it is the same as the host's. Though there are probably other concerns as well.

[anevilyak]

(In #8168) Duplicate of #7824. For the time being, the 'fix' is to replace the host's storage/Mime.h and support/TypeConstants.h with those found in trunk since that constant was moved.

[modeenf]

Now that we have 4.6 are this a problem?

[anevilyak]

Replying to modeenf:

Now that we have 4.6 are this a problem?

Yes, the fact that it's a newer version doesn't change the fact that it doesn't allow itself to be built as a cross compiler as we want it to.

[bonefish]

Replying to anevilyak:

Yes, the fact that it's a newer version doesn't change the fact that it doesn't allow itself to be built as a cross compiler as we want it to.

Have you tried with the patches/method I described in the ticket description?

[anevilyak]

Replying to bonefish:>

Have you tried with the patches/method I described in the ticket description?

Not yet but I can if you like.

[leavengood]

I'm not sure if this is fixed based on your recent Haiku blog post Oliver, but I figured I'd ping to see.

[zooey]

Replying to leavengood:

I'm not sure if this is fixed based on your recent Haiku blog post Oliver, but I figured I'd ping to see.

No, this has not been fixed yet, neither in Haiku's master nor in the package management branch. I'm going to test the strategy that the gcc_cross_x86 build recipe is using today and, if that indeed works, apply the fix.

[zooey]

Should be fixed in hrev45759.