It would be great if someone can confirm that a fresh install of Haiku, and then following these instructions will result in a successful build. It is difficult to get started when these early steps fail before one really even gets into the project. My goal was to get past the building of Haiku so that I could then explore and experiment.
I actually just finished running that exact same command and I didn’t have any issues. Did you clone the buildtools from https://review.haiku-os.org/buildtools?
Edit: Well, I created a generated/ folder first and used ../configure --build-cross-tools x86_64 --cross-tools-source ../../buildtools from it, I don’t know if that’s relevant, but I figured I should mention it
Unfortunately not, I followed the guide on https://www.haiku-os.org/guides/building/compiling-x86_64 and it worked on my end. Are you sure you are using a 64 bit install? If you are on 32 bit, I believe you can just do ./configure
For what it is worth, when I was doing the above tests I am doing this on the bare metal of a Dell machine. Today I decided to run Haiku in VirtualBox and for some reason, following the same steps, as on the pages referenced, it was able to finish building the buildtools… but when I tried to build the nightly, it failed.
Why would I be getting different results in these types of situations? Does that help pinpoint what may be happening? The output from running these commands is like a mile long… so is there some part of it that would help in diagnosing this?
Is there anyone interested in helping me resolve this? Of course a person can’t really contribute much when they can’t move past these types of hurdles.
This is definitely a frustrating part of trying to get involved. I do realize that, due to Haiku’s totally open nature, that no one is required to help… but if someone does help, and these types of hurdles can be overcome, it would seem to me that more people would be willing to get involved to contribute. One thing I find very common in these forums is that people experience difficulties that prevent an encouraging experience. Anyway, just thought it might be valuable if I shared this.
Just share the whole thing. Put it on paste.debian.net or some similar website. It will avoid rounds of you posting a part, then us asking you to post another part, and so on.
As for getting different results, it points to either you doing something differently, or the hardware or software having a problem and behaving weirdly (incompatible CPU, broken RAM, or maybe on the software side, filesystem corruption or things like that).
Without complete logs (and ideally the exact steps you used) and with no one able to reproduce the problem, there isn’t a lot we can do to help.
I can appreciate the response, but I want to emphasize one basic detail:
I download a fresh latest nightly anyboot.
I create a new instance in VirtualBox, boot up and install Haiku.
I then follow the steps to get the build tools and haiku repo by copying and pasting the two commands on the relevant Haiku pages. The only modification I make is to add the depth of 10 to minimize the download.
I then follow and copy and paste the commands for making the generated directory and running the configure.
Those are the steps I take… literally copying and pasting the commands from the pages.
The two types of Haiku environments that I have tried on are both using the 64-bit images of haiku. One on bare metal dell optiplex machine, and one in a VM using VirtualBox on my Windows 10 64-bit Dell.
My basic concern is that on both machines, which have no custom configuration, I get two results, neither successful.
So, it really seems to me that this is not a good experience. I’m just replying here on my phone, so next time I’m back in my office I’ll try again and capture the output for analysis.
One of my reasons for this thread is to at least provide the feedback that by just following the published steps, I am unable to be successful. I wanted to confirm that these pages were not out of date in some way, and that if someone else tried exactly the steps on these pages that they would be successful. My thought was that it would save me from doing these steps over and over without success just to find out the steps were outdated and wrong now.
I’m using Haiku x86_64 hrev54959 (i.e. nightly branch) for this test. This should work on Haiku R1B2. Do a ‘pkgman full-sync’ to get the latest system updates.
Ensure your folders are correct:
cd ~/ (i.e. /boot/home or go to your work partition)
I also wanted to give an update from my original post. I’ve followed the same steps each time and been sure to update my version of Haiku to the latest each time. For the past several days, I’ve followed the same steps as I listed. These steps come from the two pages:
Getting the source
Building for x86-64
The path that I’ve been working on from the root was /boot/home/Projects
I then create a new folder called hkdev to which I checkout the source. So, the buildtools and haiku directory are checked out here:
And within the haiku folder I create the generated.x86_64 directory, just as the steps indicate.
Every time I tried this on the actual hardware (not VM), I got an error during the configure step for the build tools. For some reason, today, I it was able to successfully complete the configure step for the buildtools.
Did something change between my original post and now that might have impacted this?
I will now move to the step of creating the nightly anyboot and post the results.
What hrev are you running? I ask so that I could try to give this a try on the same revision. I will probably use a VM though.
Looking at these two logs you get different errors. For the 32 one it seems you lack the tools to build the EFI image. I don’t personally know the details of that, whether those are supposed to be on the system, or if they should be installed before building, or if the build system is supposed to add them but failed to.
For the 33 one it seems that name resolution for eu.hpkg.haiku-os.org fails, your system cannot download some gcc system libs and then a link fails for lack of some .o files, probably from this package.
Also it is really wasteful to delete everything between each run, you really should not need to do that. Git checkouts and downloading all those packages is expensive, for both your machine and the Haiku servers. You should only need to delete all this if they get really messed up, and then really it should only be the generated directories. Nothing is touched in the actual Git checkout so again that should not be deleted between runs.
I would keep trying to build without deleting things and see if the errors are consistent. The fact that you get different errors between runs means something else is up, like flaky networking or something. Part of the confusion is that it seems things like failed package downloads don’t immediately make the build fail, when they probably should. You seem to only get build failures when the things provided by the packages that failed to download are needed by the build.
Thank you very much for taking the time to look into this. My main reason for checking things out each time was because I really had no idea what might be taking place on each step of the configure and build, etc. If you suggest that I don’t need to pull down fresh repos because nothing within them (except in the generated directory) is being changed, then I’ll try that approach. I’ll at least do a pull on each repo first to make sure that I have any new changes if there are any.
Each day that I try this I pull down the latest Haiku by using the Software Updater first. The one I ran today, which would be the second file is hrev54968, x86_64.
Another reason that I was deleting everything and starting over was because I was interested in simulating the first-try experience for new users. I figured if a new user can’t follow the steps and get working results, then it is going to be very hard to attract new users who feel interested in helping on the project. I would certainly have apprehensions about inviting new users to try Haiku (as a developer) if these first steps are such a hassle to get working.
Ironically this revision definitely has broken package upgrading and installing, in fact you may have trouble now upgrading from it. You may need to downgrade first to be able to get the latest nightly (if you have your previous package states), or you will need to download it manually, then install the package. This could be the reason for current building problems.
That’s totally fair. I think we should have more information about what could go wrong and what to do about it, and maybe some more details about how the build system works, and the things it needs to do (like download build packages, so there needs to be a working network connection.) Plus details like I told you that you should not need to re-download the source ever unless your Git repo gets totally messed up. Git is another thing, where maybe we just need to link to some standard documentation.
I also think it would be helpful to have some documentation about the full process to fix a bug in Haiku, from getting the source, building it, changing the code for something, rebuilding that, and then the various ways to test that changed component including some tips and tricks. Maybe we have already something like this (I would need to check) but I suspect we don’t have it all in one place where someone could follow it in a single tutorial.
I have bouts of time where I work on Haiku and then long stretches where I don’t (like a lot of people I have a job and a family and various priorities change over time.) Even though I’ve been with the project for almost 20 years on and off, I still have a little trouble getting back up to speed (plus of course things change and if you don’t keep up it can be hard to know what might be broken on a given day.)
I have tried to think of ways to make this easier, like prebuilt development VMs or something but we may have to think outside the box some. I’ve had some more crazy ideas recently related to running Haiku in the cloud and maybe a WebAssembly app which can connect to the remote app_server protocol but I don’t know how viable it is. I don’t think most developers would want to use that day to day but it might be a faster way to try things or fix something small, I don’t know. Companies like https://www.gitpod.io/ are doing some interesting things. But developing an operating system is a lot more complex than a random web app.
