PPC haiku-boot-cd-ppc broken on x86_64 Linux compiles.

[kallisti5]

gcc4 x86_64 -> ppc cross-compile

alex@eris:~/develop/haiku$ uname -a
Linux eris 2.6.28-11-generic #42-Ubuntu SMP Fri Apr 17 01:58:03 UTC 2009 x86_64 GNU/Linux
alex@eris:~/develop/haiku$ jam -q haiku-boot-cd-ppc &> ppc-build-log
.
.
KernelLd generated/objects/haiku/ppc/release/system/boot/boot_loader_openfirmware 
SetType1 generated/objects/haiku/ppc/release/system/boot/boot_loader_openfirmware 
MimeSet1 generated/objects/haiku/ppc/release/system/boot/boot_loader_openfirmware 
SetVersion1 generated/objects/haiku/ppc/release/system/boot/boot_loader_openfirmware 
setversion: Input/output error: generated/objects/haiku/ppc/release/system/boot/boot_loader_openfirmware
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:generated/objects/linux/lib
generated/objects/linux/x86/release/tools/setversion "generated/objects/haiku/ppc/release/system/boot/boot_loader_openfirmware" -system 1 0 0 a 1 -short "Developer Build" ;

...failed SetVersion1 generated/objects/haiku/ppc/release/system/boot/boot_loader_openfirmware ...
...removing generated/objects/haiku/ppc/release/system/boot/boot_loader_openfirmware
...skipped haiku-boot-cd-ppc.iso for lack of boot_loader_openfirmware...
...failed updating 1 target(s)...
...skipped 1 target(s)...
...updated 183 target(s)...

full build log is attached as ppc-build-log

[kallisti5]

ppc build log. This was Revision: 32950

[mmadia]

was this the first time you compiled ppc from x86_64 linux?

[kallisti5]

yup, this is the first time i've given it a go. It looks like something is off about the boot_loader_openfirmware binary that is created under x86_64. Jam removes boot_loader_openfirmware since the compile fails, is there any way to tell jam to leave the created file?

[kallisti5]

Skipped the SetVersion, boot-loader compiled ok... (removing -q would of done the same.. oh well)

* Jam SetVersion1 defined in build/jam/BeOSRules
* Jam SetVersion1 called by rule SetVersion in build/jam/BeOSRules
* Jam SetVersion called by rule KernelLd in build/jam/KernelRules
	* This is where the failing call is happening.
	* Commenting out SerVersion lets the bootloader compile successfully.
	  (looking back maybe not using -q would of stopped jam from removing
	  the failed bootloader.. oh well.

alex@eris:~/develop/haiku$ export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:generated/objects/linux/lib
alex@eris:~/develop/haiku$ generated/objects/linux/x86/release/tools/setversion "generated/objects/haiku/ppc/release/system/boot/boot_loader_openfirmware -system 1 0 0 a 1 -short "Developer Build" ;
setversion: Input/output error:
generated/objects/haiku/ppc/release/system/boot/boot_loader_openfirmwarealex@eris:~/develop/haiku$ 
alex@eris:~/develop/haiku$ echo $?
1
alex@eris:~/develop/haiku$ file generated/objects/haiku/ppc/release/system/boot/boot_loader_openfirmware
generated/objects/haiku/ppc/release/system/boot/boot_loader_openfirmware: ELF 32-bit MSB executable, PowerPC or cisco 4500, version 1 (SYSV), statically linked, with unknown capability 0x41000000 = 0x11676e75, with unknown capability 0x10000 = 0x90401, not stripped
alex@eris:~/develop/haiku$ 

attaching strace of setversion failing. Not sure if this is a general x86_64 bug or if it is PPC related. Does x86 haiku compile on x86_64?

alex@eris:~/develop/haiku$ strace -vvFfo strace generated/objects/linux/x86/release/tools/setversion "generated/objects/haiku/ppc/release/system/boot/boot_loader_openfirmware" -system 1 0 0 a 1 -short "Developer Build" ;

[kallisti5]

strace of failing setversion

[cdr]

I got the same problem when trying to build x86 Haiku on x86_64 Linux. The first thing I had to do to build the cross toolchain was to use linux32 to fool it into thinking it's building on i686 (well, libiberty's configure didn't detect x86_64-unknown-linux-gnu as a valid platform): $ linux32 ./configure --build-cross-tools ./buildtools/

After that the toolchain built OK, but then when I tried to actually build any part of Haiku, it failed when trying to build libroot.so with exactly the same error as in the bug report. It looked like setversion has failed.

I debugged setversion and I found out that the size of Elf32_Ehdr structure is 80 bytes instead of 52 bytes - classical portability issue. So I looked at the types in headers/os/support/SupportDefs.h and headers/[build/]os/support/SupportDefs.h and uint32 is defined as unsigned long and int32 is defined as long. 64-bit Linux follows LP64 convention meaning that long is 64-bit, so it means that [u]int32 is actually 64-bit in the cross-binaries (like e.g. setversion) used to build Haiku.

To fix it [u]int32 has to be redefined as [unsigned]int. This fix will also be needed is Haiku will ever be ported to x86_64/amd64 arch. Fixing this will also trigger changes in BString::operator<< (duplicate int and int32) as well as in a couple of other places where string formatting is done.

Please let me know if I can do anything to help to solve this. I can even provide a sample change set, but this seems easy to fix so far but will still probably require more testing.

[axeld]

Yes, we're aware of that problem - BeOS defined [u]int32 as "long", so it's part of the ABI (function signatures look different if you would change this).

For the GCC4 build we could change this now, though (causing all existing packages to be rebuilt), and for platforms other than x86 it should be changed right away, anyway.

[kallisti5]

I just did a gcc4 PowerPC build with hrev42406 on a x86_64 Debian machine and it was successful.

Someone fixed this somewhere... not sure where though :)