Building Haiku

I’ve been able to build Haiku on Linux, but not on BeOS.
(Read Copyattr Error for info).

Has anyone with an AMD processor system been able to build Haiku on BeOS??? (Yes or No).

If yes,
which did you use:
Zeta & Version # (ie: Zeta 1.2)
R5/netserver (ie: BeOS Max 3.1)
R5/Bone (ie: BeOS 5.0.3 + Bone)

What software did you install to get it to build?
Also, motherboard chipset if you know it.

I’m trying to figure out if this is a general problem or specific only to me.

I have a BeOS Max v3.1b1 install (R5.0.3) with BONE - running on a PIII though.

Per your other thread, I don’t think copyattr relies on Tracker.

I’ve heard that DevEd 1.1 had some issues though. I used it for a while years ago, but switched to Max before I ever started compiling Haiku myself.

Max comes with the AMD patch already applied - but if you install BONE, it will have to be re-patched. I think the AMD patch is required to even boot BeOS though - and I’m not sure if VMWare abstracts that or not.


  1. Same cpu as running on host computer (but limited to 32 bit & one core). (my cpu is AMD Athlon XP @ 2Ghz - which I verified with Zeta in VmWare)
  2. Emulates BX motherboard chipset. (BX, right on).

Kernel would have to be patched for AMD cpu (which I’m certain Max is).

I’ve tried to install BeOS Max, but it wouldn’t boot off the CD (which is bootable & installed previously on a dual P2). I’m going to use Dev. Ed. installer to get Max installed, use makebootable command & hopefully Max will boot afterwards.

I’m hoping I can get Haiku to build on BeOS - mainly because I wanted to see if I could get the other targets to build (ie: DANO) - Dano doesn’t build under Linux, requires BeOS host system.

I used to build on an Athlon XP 2000+ under DevEd 1.1, but that’s been a while (6+ months).

What happens when you try building? What fails?

I switched over to Dano to try building it (& hoping for a better outcome).

Came very close too.

It took like 7 hours in VmWare to build (not sure if that is on the slow side for VmWare).

It updated 9880 targets.

There are lots of failed targets, but I’m going to give the one I think is causing problems.

When doing, jam haiku-image, I get following error:
…failed C++ generated/objects/dano/x86/release/tools/set_haiku_revision.o …

because this target failed to build, I also get 5 other targets that are skipped.

PS, I did svn update prior to building on BeOS, so not sure if the newer revision is working, because I haven’t built it on Linux.

When doing jam:

…failed C++ generated/objects/dano/x86/release/tools/set_haiku_revision.o …
…skipped [build]set_haiku_revision for lack of [src!tools]set_haiku_revision.o …

I changed <> to [ ] (otherwise HTML made the words disappear).

[quote=tonestone57]When doing jam:
…failed C++ generated/objects/dano/x86/release/tools/set_haiku_revision.o …
…skipped [build]set_haiku_revision for lack of [src!tools]set_haiku_revision.o …

It would be helpful if you also include the error message… :slight_smile:

build with jam -q haiku-image instead so the build stops at the first error (makes it easier to find the error message).

I installed Dano on another Athlon XP system (w/512 MB RAM), but this time natively (no VmWare).

Still the same error, but at least it compiled faster.

jam -q haiku-image gives:

C++ generated/objects/dano/x86/release/tools/set_haiku_revision.o
/boot/home/haiku/src/tools/set_haiku_revision.cpp:21: arpa/inet.h: No such file or directory

gcc -c “src/tools/set_haiku_revision.cpp” -O2 -Wall, …, -o “generated/objects/dano/x86/release/tools/set_haiku_revision.o”;

…failed C++ generated/objects/dano/x86/release/tools/set_haiku_revision.o …
…skipped [build]set_haiku_revision for lack of [src!tools]set_haiku_revision.o …
…skipped [revisioned] for lack of [build]set_haiku_revision …
…skipped [HaikuImage]haiku.image-copy-files-dummy-beos/system/lib for lack of [revisioned]
…skipped hiku.image for lack of [HaikuImage]haiku.image-copy-files…
…failed updating 1 target(s)…
…skipped 4 target(s)…
…updated 48 target(s)…

There is no other error message showing. All the targets before compile perfectly. This is exactly what I see, expect I took out some switches from gcc to make that shorter.

  1. I’m going to try updating the src (svn update) to see if that changes anything.

  2. I’ll probably also try it with BeOS Max. And if still no go, then I’ll just have to give up on BeOS build machine and stick to compiling it on Linux (which I’ve got working).

I wanted to get it working on BeOS so that I could also try with different target platforms.

I don’t have access to the headers on dano, but you could try changing line 18 from
and see if that makes it build. I thought that header existed under bone and dano, but maybe it doesn’t.

Just so we feel better, verify you’re using the right build tools by typing these in and telling us the results:

  • gcc -dumpversion
  • jam -v

Also, you might wanna try running “jam clean” before doing the build.


gcc -dumpversion:

jam -v:
Jam 2.5-haiku-20060813. OS=BEOS. Copyright …

Whenever I rebuild I always use:

  1. jam clean
  2. cd into generated folder & rm -rf *
  3. ./configure

I think you’re on the right track.
I located ByteOrder.h & searched it. Found htonl was defined in this header file. (couldn’t find it in inet.h - so, doesn’t matter that it couldn’t find arpa/inet.h to begin with)
I did the change. I’m jamming the src/tools directory right now & logging the output to see if set_haiku_revison fails. (hmm, I guess BeOS R5 would be better for building Haiku - since that is what they use - Build Factory).

I also did an svn update (now version 20130).

Do you guys also build Haiku? On which version of BeOS (ie: Beos PE, Beos Max, Dano, Zeta 1.x, Beos Dev Ed 1.1, Beos + Bone, etc.)??? (I’m guessing it is a R5 based distro).

Do you guys also build Haiku? On which version of BeOS (ie: Beos PE, Beos Max, Dano, Zeta 1.x, Beos Dev Ed 1.1, Beos + Bone, etc.)??? (I’m guessing it is a R5 based distro).[/quote]

I’ve been building under R5, bone and dano, and all platforms worked great for building haiku (although a little slow). Nowadays, since I got my new computer (and cannot run BeOS anymore), I’m using Ubuntu Edgy which also is great for building.

BTW, you really don’t need to run “jam clean” very often, it just takes more time to build then. I can’t recall many times I’ve had to do that.

It should be right here on the webpage, plain R5 they use I think but the webpage I saw it on was the old webpage.

Take a look at you’ll see at the build machine is a P4 running R5 Pro netserver

Thanks to everyone for their posts.

@ nutela
Build Factory page has the Build Machine Specs. (I’ve seen them before).

@ Fredrik
You were right. I did the change & it compiled on Dano. I hope you tell one of the developers to make it permanent.

I’m very happy it was only 1 line of code that needed changing for it to build on Dano.

Also, good point about jam clean. It does take a long time to build from clean/fresh (little over 3 hours on Athlon XP 1800 with 512MB RAM). I think Linux built it faster, but then again, Linux is a more updated OS (compared to BeOS R5 or Dano).