Building woes with HaikuPorts on x86(_gcc2)

Disclaimer first: I know very well nothing is perfect, and a lot of work needs to be done on certain aspects of HaikuPorts. That said…

I’ve been trying for a while now to get certain recipes to build in HaikuPorts on my netbook (running R1Beta3-x86_gcc2), but several of the recipes I have tried so far have failed to even get anywhere. I know x86_gcc2 is not an ideal architecture for most of the recipes, and in fact nearly all the ones I have looked at even are marked as broken on the architecture. To get around that, I used the ‘search x86’ command in a terminal to switch over, but this still doesn’t seem to have made any difference; the recipe still fails at the start with the message:

$RECIPENAME is reported as broken on this architecture

Tested and failed recipes (so far) are:

  • scummvm
  • simh
  • fs-uae
  • yt-dlp

Is there a way of perhaps changing my architecture permanently to x86 on this setup? I don’t really have a need for BeOS backwards compatibility on my netbook’s setup so getting off of the need for gcc2 wouldn’t be a major loss.

sounds like you misconfigure haikuporter, it should use x86 automatically for almost everything.

setarch does not matter, haikuporter configure the build env itself

HaikuPorter does not use the arches as defined by setarch, it creates a chroot and sub-shells with configurations itself. In order to build recipes with the setarch x86 compiler, you must add it as a suffix on the recipe name, e.g. haikuporter scummvm_x86.

2 Likes

Make sure you enable secondary architecture in the haikuports config file

https://github.com/haikuports/haikuporter/blob/master/haikuports-sample.conf#L73 (enable that line)

1 Like

Easiest way is to stop using 32 bit Haiku alltogether. No gcc2, no secondary arch, no _x86 postfix for hp, and many more!

1 Like

And why? So far things have been pretty OK with 32bit, it’s only that not much of the core dev’s seem to take an interest to it (haikuports) …
You can still learn a lot by trying to solve things on both arch’s …

2 Likes

Agreed. And the replies here are part of that learning process!

Yeah, I might ask a bunch of questions, but not only am I learning and benefitting from doing so, but new Haiku users will also benefit from having good questions with good answers here, so I see it as a win-win for everyone! :slight_smile:

3 Likes

Maybe both of you have right in a specific point of view but not everybody interested in computing-archeology, and we have seen how much misunderstanding were around Haiku as even big news sites mis-reported Haiku supports only ancient gcc, because they followed the minimum-energy theory and just typed gcc -v in Terminal without reading any documentation (it is u*ix, I know this!), we can just estimate how many people decided not to try Haiku because this.

32 bit with the secondary arch also represents an unnecessary abstraction level, which increases complexity and makes the system harder to explore/understand. Also we have seen how many people are lazy enough to not even check the gcc version but going straight and trying compile recent software with it and posting gcc2’s cryptic errors here.

But yeah, one can learn from it, the question is how useful this knowledge if some people prefixes then everythong with “setarch x86” after they learnt about it believing they now understanding the system only to fail hard with haikuporter.

On the other hand 64 bit doesnt require you to re-learn anything.

On one hand, I have never used x86_32 versions of Haiku but on the other hand, are there sufficient 64-bit alternatives to all the 32-bit closed-source BeOS programs?

I don’t pretend to be a developer and don’t know the internals on Haiku or how hard it is to maintain 32bit architecture, that is something I leave to the developers there (but I haven’t seen any recent changes that would be 32bit specific when I’m online on IRC).

I hardly use gcc2 there myself, nothing is really needing it atm, only parts that have been ported and should be compatible there for some dependencies I guess. (So I’m not posting ggc2’s cryptic errors) :slight_smile:

Even on 64bit things fail with haikuporter that runs fine when build from Terminal. :slight_smile:

That was maybe true 10 years ago, but surely by now people who don’t care to check gcc versions closely will also download the 64bit version?

So now, we are safe from this problem. And if people want to enjoy the extra fun and complications of using the 32bit version for whatever reason (very old hardware, wanting to run BeOS apps, …) it’s fine, let them do that. Getting into arguments about it everytime someone talks about the 32bit version is also a good way to make people think “this community is very toxic, they get angry when I use software they provide and pretend to support” and surely that will also convince them to not use Haiku.

So, I would suggest you stop doing that :slight_smile: If you think the gcc2 version should be removed, please take your complaints to the developers, maybe on the development mailing list or on the bugtracker. Not on users who have chosen to use that version. Thanks!

4 Likes

Maybe we could make the modern gcc the default and have people use setarch when they explictly want to switch to gcc2.

1 Like