Opened 8 years ago

Closed 6 years ago

#7824 closed bug (fixed)

Cross-Compiling gcc 4 on Haiku broken

Reported by: bonefish Owned by: zooey
Priority: blocker Milestone: R1
Component: Build System Version: R1/Development
Keywords: Cc: siarzhuk, modeenf, mdisreali@…
Blocked By: Blocking: #8168
Has a Patch: no Platform: All

Description

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.

Attachments (2)

gcc-cross-compiler.diff (551 bytes) - added by bonefish 8 years ago.
Patch for buildtools introducing --enable-cross-compiler gcc 4 configure option
haiku-cross-compiler.diff (566 bytes) - added by bonefish 8 years ago.
Patch for build/scripts/build_cross_tools_gcc4 using the --enable-cross-compiler option

Download all attachments as: .zip

Change History (18)

Changed 8 years ago by bonefish

Attachment: gcc-cross-compiler.diff added

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

Changed 8 years ago by bonefish

Attachment: haiku-cross-compiler.diff added

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

comment:1 Changed 8 years ago by siarzhuk

Cc: siarzhuk added

comment:2 Changed 8 years ago by modeenf

Cc: modeenf added

I also have this problem :)

comment:3 Changed 8 years ago by 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.

comment:4 in reply to:  3 Changed 8 years ago by 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).

comment:5 Changed 8 years ago by Disreali

Cc: mdisreali@… added

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

comment:6 in reply to:  5 Changed 7 years ago by 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.

comment:7 Changed 7 years ago by 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.

comment:8 Changed 7 years ago by anevilyak

Blocking: 8168 added

(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.

comment:9 Changed 7 years ago by modeenf

Now that we have 4.6 are this a problem?

comment:10 in reply to:  9 ; Changed 7 years ago by 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.

comment:11 in reply to:  10 ; Changed 7 years ago by 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?

comment:12 in reply to:  11 Changed 7 years ago by 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.

comment:13 Changed 6 years ago by zooey

Owner: changed from bonefish to zooey
Status: newin-progress

comment:14 Changed 6 years ago by 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.

comment:15 in reply to:  14 Changed 6 years ago by 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.

comment:16 Changed 6 years ago by zooey

Resolution: fixed
Status: in-progressclosed

Should be fixed in hrev45759.

Note: See TracTickets for help on using tickets.