The kernel is irrelevant because it’s modern GCC only now and uses C++11 features in some places. libbe.so on the other hand does use some parts of the STL, like std::vector, std::string, and std::list at least, off the top of my head.
Are they part of the public API/ABI? In other words, would the whole ecosystem collapse if std::vector suddenly becomes std::__1::vector instead?
In some cases, like BString, yes.
Interesting, I see no std:: in BString (headers/os/support/String.h) 
Hmm, I thought there was a converter here… I guess it must be in some other header.
Well, anyway, I think the overall utility would be massively reduced if the STL was somehow an exception to ABI compatibility. Having a near drop-in replacement for GCC2 is really the ideal, I think.
Fortunately it is not - once again, if this effort gains more traction and if Haiku maintainers are willing to review and accept mass refactors to make GCC2 headers conform to standards, we can gain 100% ABI compatibility with the legacy C++ library.
I think this is not too bad of an idea, because:
- Haiku already has downstream patches in the headers, and
- That version of
libstdc++is already long dead, and therefore no upstream synchronization is needed.
On the other hand, making Clang a true drop-in GCC2 replacement is impossible, since the LLVM maintainers clearly reject the idea of relaxing the language parser rules. From the LLVM Discourse:
My version of an ideal would be:
- Binary compatibility with all public
libbe.soand similar legacy Haiku APIs (which I believe should not pull instd::stuff), and - A modern C++ library that peacefully coexists with whatever else is loaded in the address space to enable modern ports (and kill
setarch/hybrids completely). - Binary (not source) compatibility with the legacy C++ library. This should be done by compiling only the system library against a (potentially patched) set of legacy headers. Future builds of open-source software should migrate to what is mentioned in 2.
1 Like
For the most part all code we compile with GCC2 also compiles with modern GCC and Clang, so I don’t think we have too much code to adapt to C++98 rules besides the STL. So if we can make enough adjustments that we can consider replacing GCC2 at least for OS builds, that will be very valuable.
1 Like
We now have a full Clang build targeting x86_gcc2 Haiku (look at the stage3.haiku artifact):
Build LLVM GCC2 · trungnt2910/llvm-gcc2@667ebba
It is currently not running yet since it is blocked on an issue with runtime_loader (that is not architecture-specific and can also be reproduced on x86_64 Haiku):
#20126 (runtime_loader resolves symbols to incorrect type) – Haiku
There is also this small patch that enables TLS infrastructure on x86_gcc2 Haiku:
libroot: Unconditionally include TLS symbols (11059) · Gerrit Code Review
runtime_loader has always included this infrastructure; it is just the original author guarding the libroot.so glue code for unknown reasons. The patch has already gotten +1 from waddlesplash so I hope it can get in without too much trouble.
5 Likes
UPDATE: Linux also has this symbol clash if given the right (wrong?) linker flags. I have fixed the build script and new builds are currently being made.
To moderators, please strikethrough or delete this section in the previous post to prevent confusion:
It is currently not running yet since it is blocked on an issue with runtime_loader (that is not architecture-specific and can also be reproduced on x86_64 Haiku):
#20126 (runtime_loader resolves symbols to incorrect type) – Haiku
We now have a working toolchain on Haiku x86_gcc2.
You can download the binaries here: Build LLVM GCC2 · trungnt2910/llvm-gcc2@5b18634, or run the scripts from that repo to build the toolchain from source.
5 Likes
Nice progress! Does this define _GNUC_ == 2.95, and is thus actually compatible with existing legacy GCC BeOS binaries already? At least I would have assumed this to be much more work still.
1 Like
It does not right now.
If it just about mangling names and laying out structs the right way, it should be. But I believe there are places where this macro is used to make some breaking changes like having slightly different function signatures, in which case it is not.
We can handle this on the driver side once the core is finished - perhaps a special i586-pc-haiku-gcc2 target with this macro defined, or maybe decouple the ABI from the compiler version and rely on Haiku config headers instead.
There is much more work ahead. The branch we currently have is low-quality LLM output. If the Clang team accepts the idea of having a GCC2 backend, I will start cleaning up the slop and upstream the changes. I would expect this to be at least 10+ PRs over the span of 1 year.
2 Likes
RFC: Revitalization of the x86_gcc2 ecosystem - Feedback / Ideas - Haiku Community
I need your support to get approval from LLVM. Please provide your thoughts here.
Thanks a lot!