Haiku fails to compile in 32 bits due to "objcopy"

[AGMS]

Can no longer compile Haiku in 32 bit mode, tested with a fresh install of Haiku in a VM, new disk etc. hrev55847

The trouble seems to be that the EFI boot image involves using objcopy to copy the executable code segments to a "pei-i386" target. However, both objcopy (gcc2) and objcopy-x86 don't support it. Just 64 bit objcopy supports it as a target.

Probably need to update a recipe on HaikuPorts...

Does the continuous integration build test system detect this sort of problem?

[AGMS]

Haiku GCC2 Hybrid binutils versions as what's made available by the HaikuPorts repository...

gcc2: 2.17_2016 x86: 2.26.1_2016

Haiku 64 binutil version: x86_64: 2.31.1

[waddlesplash]

This does not seem to be a versioning problem but instead may be some kind of misconfiguration to our binutils exposed by the recent EFI changes. CC'ing davidkaroly.

[waddlesplash]

Addendum: you mentioned on IRC that using cross-tools does not help. That should be using a newer version of binutils. Can you provide logs for that configuration?

[AGMS]

Cross-tools fails in the configure stage, with that dreaded m32 problem. Was using this command from within generated, which is at same level as the haiku directory, not inside (avoids grepping compiled stuff when searching for things inside haiku directory):

../haiku/configure --cross-tools-source ../buildtools --build-cross-tools x86_gcc2 --build-cross-tools x86

make[1]: Leaving directory '/boot/home/Haiku-OS-Source/generated/cross-tools-x86_gcc2-build/binutils'
Copying /boot/home/Haiku-OS-Source/generated/cross-tools-x86_gcc2-build/syslibs to /boot/home/Haiku-OS-Source/generated/cross-tools-x86_gcc2/i586-pc-haiku/lib
Copying /boot/home/Haiku-OS-Source/generated/cross-tools-x86_gcc2-build/sysincludes to /boot/home/Haiku-OS-Source/generated/cross-tools-x86_gcc2/i586-pc-haiku/sys-include
Created "Makefile" in /boot/home/Haiku-OS-Source/generated/cross-tools-x86_gcc2-build/gcc using "mh-frag" and "mt-frag"
cc1: Invalid option `32'
*** The command 'gcc -m32 -o conftest -O2 -U_FORTIFY_SOURCE -fcommon   conftest.c' failed.
*** You must set the environment variable CC to a working compiler.

It also fails the same way with generated in the conventional place, using command:

../configure --cross-tools-source ../../buildtools --build-cross-tools x86_gcc2 --build-cross-tools x86

[waddlesplash]

You can disable -m32 on 32-bit Haiku in the build script.

[AGMS]

Looks like a bad case of bitrot due to time passing and people adding new code that breaks things.

I hacked up build/scripts/build_cross_tools to remove the -m32. That worked.

Fixed the C code to have variables declared at the start of a block, can't do that in the middle, affects binutils/libiberty/cp-demangle.c, d-demangle.c, pex-unix.c

Now stuck on M4 macros for detecting the compiler misfiring and adding a -Wstack-usage=262144 all over the place. binutils/bfd/archive.c fails to compile because of that.

There is code to detect the compiler version, and skips the unwanted argument for versions 0 to 4. Perhaps the version 11 looks like it starts with 1, though that shouldn't affect version 2 detection? Also that test is all over the place, not sure if that is copy and paste code or if there is a master macro for it somewhere that got copied everywhere. Need someone who can debug M4 code; I don't even know how to stick in a print statement. Did try commenting out the rules in binutils/bfd/warning.m4 but that didn't fix it.

[pulkomandy]

Fixed the C code to have variables declared at the start of a block, can't do that in the middle, affects binutils/libiberty/cp-demangle.c, d-demangle.c, pex-unix.c

Quite likely trying to build gcc11 using gcc2 will not go so well anyway...

I guess the best option is to run Haiku configure script inside a 'setarch x86' shell, so both versions of gcc are built using gcc11?

Once you have that working, you should be able to compile Haiku normally.

[jmairboeck]

According to the ​Changes page, GCC 11 requires a C++11 compiler to build, i.e. at least GCC 4.8 or later.

[AGMS]

I'll give setarch a shot. If it works, I'll put in a web site documentation update for that.

[AGMS]

OK, it works if you do a "setarch x86" before running configure with the hybrid build options. It also needs libzstd for x86, so the software prereqs are actually:

pkgman install cmd:python3 cmd:xorriso devel:libzstd devel:libzstd_x86

Then for the actual jam to build Haiku, you also need "setarch x86", otherwise it fails very quickly when building its anyboot tool:

gcc -c "../haiku/src/tools/anyboot/anyboot.cpp" -O2 -Wall -Wno-trigraphs -Wno-ctor-dtor-privacy -Woverloaded-virtual -Wpointer-arith -Wcast-align -Wsign-compare -Wno-multichar -include ../haiku/headers/build/HaikuBuildCompatibility.h -DARCH_x86 -D_NO_INLINE_ASM -D__NO_INLINE__ -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -DHAIKU_HOST_USE_XATTR -DHAIKU_HOST_PLATFORM_HAIKU -DHAIKU_PACKAGING_ARCH=\"x86_gcc2\" -iquote ../haiku/build/user_config_headers -iquote ../haiku/build/config_headers -iquote ../haiku/src/tools/anyboot -iquote objects/common/tools/anyboot -iquote objects/haiku_host/x86/common/tools/anyboot -iquote objects/haiku/x86_gcc2/common/tools/anyboot -I ../haiku/headers/build/host/haiku_host -o "objects/haiku_host/x86/release/tools/anyboot/anyboot.o"

gcc: cannot specify -o with -c or -S and multiple compilations 

Looks like some documentation updates are needed.

The actual compile fails too, even with setarch x86.

C++ objects/haiku/x86_gcc2/release/kits/game/FileGameSound.o 
/tmp/cc9KDZYW.s: Assembler messages:
/tmp/cc9KDZYW.s:894: Error: unbalanced parenthesis in operand 1.
/tmp/cc9KDZYW.s:2297: Error: junk at end of line, first unrecognized character is `('
/tmp/cc9KDZYW.s:2298: Error: unrecognized symbol type ""
/tmp/cc9KDZYW.s:2298: Error: junk at end of line, first unrecognized character is `('
/tmp/cc9KDZYW.s:2299: Error: invalid character '_' in mnemonic
/tmp/cc9KDZYW.s:2395: Error: expected comma after name `FillBuffer__H4Zllm214748364' in .size directive

/boot/home/Haiku-OS-Source/generated/cross-tools-x86_gcc2/bin/i586-pc-haiku-gcc -c "../haiku/src/kits/game/FileGameSound.cpp" -O2 -Wall -Wno-multichar -Wpointer-arith -Wsign-compare -Wno-ctor-dtor-privacy -Woverloaded-virtual -Werror -march=pentium -nostdinc -DARCH_x86 -D_BEOS_R5_COMPATIBLE_ -D__HAIKU_PRIMARY_PACKAGING_ARCH=\"x86_gcc2\" -DHAIKU_DISTRO_COMPATIBILITY_DEFAULT -DHAIKU_TARGET_PLATFORM_HAIKU -DHAIKU_REGULAR_BUILD -I../haiku/build/user_config_headers -I../haiku/build/config_headers -I../haiku/src/kits/game -Iobjects/common/kits/game -Iobjects/haiku_host/x86/common/kits/game -Iobjects/haiku/x86_gcc2/common/kits/game -I- -I../haiku/headers/private/app -I../haiku/headers/private/interface -I../haiku/headers/private/input -I../haiku/src/kits/game -I../haiku/headers/cpp -I../haiku/headers/glibc -I../haiku/headers/posix -I../haiku/headers/build/gcc-2.95.3 -I../haiku/headers -I../haiku/headers/os -I../haiku/headers/os/add-ons -I../haiku/headers/os/add-ons/file_system -I../haiku/headers/os/add-ons/graphics -I../haiku/headers/os/add-ons/input_server -I../haiku/headers/os/add-ons/registrar -I../haiku/headers/os/add-ons/screen_saver -I../haiku/headers/os/add-ons/tracker -I../haiku/headers/os/app -I../haiku/headers/os/device -I../haiku/headers/os/drivers -I../haiku/headers/os/game -I../haiku/headers/os/interface -I../haiku/headers/os/kernel -I../haiku/headers/os/locale -I../haiku/headers/os/media -I../haiku/headers/os/mail -I../haiku/headers/os/midi -I../haiku/headers/os/midi2 -I../haiku/headers/os/net -I../haiku/headers/os/storage -I../haiku/headers/os/support -I../haiku/headers/os/translation -I../haiku/headers/private/. -o "objects/haiku/x86_gcc2/release/kits/game/FileGameSound.o"

Looks like you can't currently build hybrid Haiku in 32 bit mode.

Though if you edit src/system/boot/Jamfile to change "pei-i386" to "elf32-i386" (temporary hack for the objcopy problem) and fix up src/add-ons/kernel/file_systems/fat/iter.h to move C++ struct diri field init constants into a constructor, it can compile Haiku OS.

[pulkomandy]

Confirmed problem on my install. Moving to beta4 blocker, as Haiku is supposed to be self-hosting.

[AGMS]

By the way, there's a patch for the FAT iter.h not compiling in GCC2 problem in ​https://review.haiku-os.org/c/haiku/+/4995

[pulkomandy]

I didn't manage to get that far.

Here is what I tried:

• Adding i386_pei_vec to selvecs in our binutils fork for building on Haiku
• Updating haikuports binutils recipe to the latest version in our repository (currently haikuports is stuck at binutils 2.26, with all newer recipes not based on our buildtools repo, and pointing to a bug that has since been closed with "I guess that's fixed" when it probably isn't?
• Tried to use these binutils to run a build-cross-tools with my changes
• I got a linker error complaining that zstd is not found. Apparently ld can now use zstd to compress debug infos and make smaller debug .so files, but there is some trouble with that when cross compiling. I'm trying to enable or disable it in the build-cross-tools script
• If I get this to work I hope to be able to test my change to selvecs, then update the haikuports binutils recipe to include that, so we can run the build again (or see about the next issue...)

[pulkomandy]

We now have binutils 2.36.1 in Haikuports (just pushed a few seconds ago). With this version I was able to build Haiku without any problems (no building of buildtools and no setarch needed).

I did not hit the problem with fatfs. If I read your logs correctly, it happens only if you build an anyboot image, while building the "anyboot" tool used to generate that image. So you can instead build a raw image or use the @install profile to build directly to a target BFS partition (which is what I use because it's a lot faster).

Not really a solution, but it gives a workaround for now until we can figure out how to best fix this.

[waddlesplash]

The objcopy problem has been fixed, so this ticket can be closed. Discussion about FAT continues on Gerrit.