Opened 13 years ago

Closed 12 years ago

Last modified 9 years ago

#845 closed bug (fixed)

Haiku fails to build on x86_64 Linux

Reported by: johndrinkwater Owned by: bonefish
Priority: normal Milestone: R1
Component: Build System Version: R1/pre-alpha1
Keywords: Cc:
Blocked By: Blocking:
Has a Patch: no Platform: x86-64

Description

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

Attachments (1)

amd64.diff (4.3 KB) - added by korli 12 years ago.
amd64 patch (doesn't work for intel 32 bits)

Download all attachments as: .zip

Change History (18)

comment:1 in reply to:  description ; Changed 13 years ago by jackburton

Owner: changed from admin to bonefish

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_ */

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

comment:3 in reply to:  2 Changed 13 years ago by 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.

comment:4 Changed 13 years ago by jackburton

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

comment:5 Changed 13 years ago by wkornewald

Milestone: R1
Version: R1 development

comment:6 Changed 12 years ago by wkornewald

Platform: Allx64

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

comment:8 in reply to:  1 Changed 12 years ago by bonefish

Summary: Build system "ignores" arch parameter on x86_64 hostsHaiku fails to build on x86_64 Linux

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.

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

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

Changed 12 years ago by korli

Attachment: amd64.diff added

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

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

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

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

comment:14 Changed 12 years ago by jackburton

Can this bug be closed ?

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

comment:16 Changed 12 years ago by bonefish

Resolution: fixed
Status: newclosed

comment:17 Changed 9 years ago by mmadia

Platform: x64x86-64
Note: See TracTickets for help on using tickets.