Haiku fails to build on x86_64 Linux

[johndrinkwater]

How to reproduce:
Run on a x86_64 hosted machine, fyi, Fedora Core 4 on an AMD 64. ./configure --build-cross-tools-gcc4 x86 ../buildtools/
jam haiku-image

Building fails.

Expected: Building completes, making a 32bit ABI-incompatible-with-BeOS Haiku image.

For some reason, __INTEL__ isn't defined when using this cross-compiler, wouldn't that be needed for the "x86" arch parameter? If not, would a test for x86 arch rather than __INTEL__ be more sensible in BeBuild?

Building errors:

headers/os/BeBuild.h:36:3: error: #error Configure BeBuild.h for your platform
To correct, you can add defined(__amd64__) || defined(__x86_64__) to the PPC entry, and the entry further down to enable ELF binary support.

Further errors after correcting issue:

InitScript1 generated/haiku.image-init-vars C++ generated/objects/linux/release/tests/add-ons/kernel/file_systems/bfs/bfs_shell/Volume.o /Haiku/generated/cross-tools/lib/gcc/i586-pc-haiku/4.0.2/../../../../include/c++/4.0.2/new:84: error: ‘operator new’ takes type ‘size_t’ (‘long unsigned int’) as first parameter /Haiku/generated/cross-tools/lib/gcc/i586-pc-haiku/4.0.2/../../../../include/c++/4.0.2/new:85: error: ‘operator new’ takes type ‘size_t’ (‘long unsigned int’) as first parameter /Haiku/generated/cross-tools/lib/gcc/i586-pc-haiku/4.0.2/../../../../include/c++/4.0.2/new:88: error: ‘operator new’ takes type ‘size_t’ (‘long unsigned int’) as first parameter /Haiku/generated/cross-tools/lib/gcc/i586-pc-haiku/4.0.2/../../../../include/c++/4.0.2/new:89: error: ‘operator new’ takes type ‘size_t’ (‘long unsigned int’) as first parameter /Haiku/generated/cross-tools/lib/gcc/i586-pc-haiku/4.0.2/../../../../include/c++/4.0.2/new:94: error: ‘operator new’ takes type ‘size_t’ (‘long unsigned int’) as first parameter /Haiku/generated/cross-tools/lib/gcc/i586-pc-haiku/4.0.2/../../../../include/c++/4.0.2/new:95: error: ‘operator new’ takes type ‘size_t’ (‘long unsigned int’) as first parameter … lots of this message per each file.

---

I know little about these things - will be happy to test fixes if you're low on x86_64 machines ;)

gcc -dumpmachine x86_64-redhat-linux ./generated/cross-tools/bin/i586-pc-haiku-gcc -dumpmachine i586-pc-haiku

[jackburton]

Our size_t.h file could be the cause of the problem:

​http://svn.berlios.de/viewcvs/haiku/haiku/trunk/headers/posix/size_t.h?rev=11769&view=markup

#ifndef _SIZE_T_H_ #define _SIZE_T_H_

/*

• XXX serious hack that doesn't really solve the problem.
• As of right now, some versions of the toolchain expect size_t to
• be unsigned long (newer ones than 2.95.2 and beos), and the older
• ones need it to be unsigned int. It's an actual failure when
• operator new is declared. This will have to be resolved in the future. */

#ifdef BEOS typedef unsigned long size_t; typedef signed long ssize_t; #else typedef unsigned int size_t; typedef signed int ssize_t; #endif

#endif /* _SIZE_T_H_ */

[johndrinkwater]

Just to verify, the above suggestion corrects the size_t problems. What we need to do for newer gccs, is to use the top set of typedefs.

[jackburton]

Replying to johndrinkwater:

Just to verify, the above suggestion corrects the size_t problems. What we need to do for newer gccs, is to use the top set of typedefs.

Only for AMD64, I think.

[jackburton]

Another thing I noticed... we don't have a "new" header in our public headers.

[bonefish]

Replying to jackburton:

Another thing I noticed... we don't have a "new" header in our public headers.

That's how it should be. <new> is a header provided by the compiler.

[bonefish]

Replying to jackburton:

Our size_t.h file could be the cause of the problem:

​http://svn.berlios.de/viewcvs/haiku/haiku/trunk/headers/posix/size_t.h?rev=11769&view=markup

<size_t.h> is indeed a problem. Well, it actually isn't -- the bfs_shell is. Theoretically we could and should remove the hack in <size_t.h>. That would break the utterly annoying bfs_shell build environment, though. I suppose we'll have to clean that one up first or we'll end up adding more hacks to Haiku code.

[bonefish]

As of hrev21011 the size_t issue should no longer exist. The new bfs_shell should have a better chance to build (and work) on previously unsupported platforms. So, if someone could retry building on x86_64 with a current revision, odds are that remaining problems will be relatively easy to fix.

[korli]

I tried to build and indeed I had to export "-DINTEL -fPIC" as CCFLAGS.

There are a lot of issues identified in the following patch.

[korli]

amd64 patch (doesn't work for intel 32 bits)

[bonefish]

Replying to korli:

I tried to build and indeed I had to export "-DINTEL -fPIC" as CCFLAGS.

Why is -fPIC needed?

There are a lot of issues identified in the following patch.

Please don't apply the patch as is. The *int32* -> *int64* changes -- or more generally, all casts from pointers to integers -- should rather use addr_t or, in the FS Shell code, fssh_addr_t. The definition of fssh_addr_t obviously needs to be conditional. I guess it would make sense to introduce a macro somewhere, which tells whether this is a 64 bit architecture.

[korli]

Replying to bonefish:

Why is -fPIC needed?

to build shared libraries correctly. ld is not happy with objects not linked with -fPIC

There are a lot of issues identified in the following patch.

Please don't apply the patch as is. The *int32* -> *int64* changes -- or more generally, all casts from pointers to integers -- should rather use addr_t or, in the FS Shell code, fssh_addr_t. The definition of fssh_addr_t obviously needs to be conditional. I guess it would make sense to introduce a macro somewhere, which tells whether this is a 64 bit architecture.

Actually this "patch" was more meant to show the places I had to change. I don't have experience with gcc on 64 bit architecture. Which macro could I check for 32 bit vs 64 bit ?

[etteyafed]

Replying to johndrinkwater:

I can now build gcc4 and haiku with gcc4 on x86_64 but not with gcc 2.95.x yet.

This may be unneeded info, but I didn't have time to read the follow ups completely.

[jackburton]

Can this bug be closed ?

[ekdahl]

Yes, it works fine for me at least.

Just configure with --use-32bit and install multilib gcc and g++ to get 32 bit libc, libstdc++ and libsupc++ libraries.