This would be possible for BUILD_PREREQUIRES as well. (Keep in mind that there is no $secondaryArchSuffix when targetting a primary architecture.)
But I think the easier solution would be to just let llvm_clang provide a name without the suffix, if it is supposed to be compatible with the primary architecture `x86_gcc2` and don’t care about $secondaryArchSuffix at all.
the gcc2 ABI is dead, there is no reason to bring it back, it has known deficiences why it was abandoned, and unless it can support literally all of modern C++ what is the point?
setarch x86 is a script that just sets env variables to another compiler.
And to be a bit more clear, ports that build for gcc2 are almost always a mistake, anything modern should target x86 only. The gcc2 part is only for the Operating system to provide binary compat with already existing compiled applications from BeOS, not to add more to the mix. This effort seems to be going backwards….
(and in any case, we still have the “native” 32bit with no gcc2 port of Haiku, we could always restart that, fix the 64bit timestamps and put the abi compat behind some compat layer…)
Why are we still preferring to have two sets of compilers and libraries when we could just have one?
Again, even if we use the ABI compat layer strategy, we would need to have a tool that knows both ABIs. Then we’ll need to handle all the marshalling edge cases…
So, do you propose to also switch everything we have to this new frankenstein abi on 64bit? Because if not we would have 4 to support on 64bit, those compiled against gcc2, those compiled against x86 and those compiled against your new hybrid abi, and the classic “ITanium” ones.
I don’t think deprecating compatibility with all Haiku 32bit applications in favor of 32bit BeOS applications makes any sense. If you do not drop this abi support, well, you still have the x86 userland to work with, it still needs to be supported. In effect you aren’t removing two abis and replacing them, you are adding a third to 32bit.
One library that supports a fixed api surface should be much easier to do and maintain than having three abis…
The $secondaryArchSuffix stuff for Haikuports is a Haikuports thing, it can be removed by reorganizing where and how we mount packages slightly, there is no need to add /x86/ in the path if the package manager would do this itself.
(edit: also as a side note, I fail to see why you’d need or want to compile your compiler as that ABI just to build for that abi…)
I fail to see how 64-bit is relevant here. 64-bit is an entirely different environment that requires a completely separate toolchain and libraries. Even if we somehow manage to get 32-bit teams on 64-bit, they would never be able to call 32-bit libraries, regardless of what the ABI of the 32-bit version is.
I don’t see how this is hybrid. While it does use Itanium-like mangling to implement modern C++ features, from the system libraries and runtime_loader’s perspective, it is no different than any valid GCC2 ABI binary.
We can still keep them around, but both will use the same compiler and very similar build configuration, which means less work for everyone.
The compiler experiment was more of a demonstration of how the toolchain is developed enough to port a complex C++ codebase to GCC2. It is definitely not required to port Clang to GCC2 just to build for x86_gcc2.
I really wonder why setarch x86 is still not the default on 32bit Haiku?
What speaks against building all applications that can be built from source with the modern compiler by default and still keep the stable ABI around for the few legacy BeOS apps that are still in use?
I don’t see any reason why someone making a modern Haiku application would still want to use GCC2.
This proposal sounds like a step backwards to me,as you’re trying to do more stuff with GCC2 instead of the modern toolchain again.
Having setarch x86 as default and GCC2 as the weird non-standard thing you switch to if absolutely unavoidable,and also renaming packages to remove the _x86 suffix from modern applications and adding a _gcc2 suffix to the few remaining apps that still need the old GCC2 would do much more to avoid confusion for newcomers.
Most people would probably never get in touch with the old GCC2 stuff anymore that way.
I do not pretend I understand the technical stuff, but I would like to offer an advice … as I see you have an idea would serve some usefulness from your perspective. However seems like everyone pick something from your idea.
I think you should draw or scheme the Big picture to illustrate what would fall out in software side both Haiku and apps if they would follow the new line you want to build for future. I assume it needed to be on the same page. They all have a picture based on their knowledge, so this may differ from your picture you are talking about.
You should illustrate how the things work now - as you see
and
the future version you propose instead. It does not matter how deep their knowledge, if this deepness is elsewhere by person. In verbally or written the idea you want to offer may slide away by misunderstanding - I mean how they have the necessary details built up in persons.
You may have more supporters if you are on the same page - and an illustraion may help to understand that better.
Whilst I think that maintaining BeOS compatibility is of limited (or no) benefit to most people, I would like to see Haiku continuing to offer a 32 bit version for those madmen like me who like to use old computers.
Are there many (users of) old BeOS apps who would benefit from this? I feel it’s a technically very interesting and advanced technique, but in the end of very limited use to Haiku. I know you’re a very smart and capable developer @trungnt2910 but I’m sure your skills could be more useful in other areas. Of course, you decide what to work on, not me
There was GCC4 hybrid build where modern GCC was default and legacy GCC was specified with setarch. Unfortunately it is abandoned and not available anymore. I think that GCC4+ hybrid Haiku makes more sense today than GCC2 Haiku.
I think the problem with the default the other way round is that the paths of libraries etc. may not be what a BeOS app expects. Everything targetting the modern toolchain is “new” however and can be adjusted if needed.
The problem is that you can’t load gcc2 Tracker add-ons, media add-ons, screensavers, etc… in a gcc4 hybrid, and so you lose some compatibility with BeOS.
To avoid needing two versions of Tracker and possibly other system apps,they can continue to be GCC2 even with my idea from above.
Only non-system apps and the GCC you call by default without using any setarch should really be the modern one in my opinion.
Changing the default compiler for non-system apps shouldn’t break compatibility in any way.
Would this development make it easier to support 32-bit applications on 64-bit Haiku? That’s the only reason for me to use the 32-bit version of Haiku.
