Was wondering if it’s okay to ask a couple of noobish-sounding questions, I’ve been having a browse online and not seen anything conclusive so far, so maybe I’m looking in the wrong places. Is it alright if I keep this thread open for this purpose and add a few more as and when I find anything else to ask?
For internal code, i.e. the kernel, API, servers - anything considered part of Haiku itself, what are the rules/guidelines on the correct version of the language standard to support and write code for?
To give a little background, I hit a build error (64-bit, so GCC9, which will be stricter) for passing a size_t as %d to a format string; this code was disabled by default by the preprocessor so may be quite old but not have surfaced in a while, depending if anyone needed to have a play. I looked up to check that the correct token as of the present day is %zu, but this is a revision that features in the C99 or C++11 standards, which of course, GCC2 cannot target at all in the case of the latter. So I was wondering if there’s some official guidance on what standards version userspace/kernel components of Haiku have to target. I know it can be a bit more complicated too, since I’ve seen on various *nix platforms how the standard library falls back on the OS in question, meaning there can be quite a headache of compatibility for things like string handling between linux/BSD/solaris/whatever, where each is subtly different. Am I right though in that we sidestep quite a bit of that with a nice clean POSIX implementation of the standard library?
For developing within Haiku, what do I need to do for a basic compiler setup? I’ve used setarch and installed gcc, gcc_systemlibs_devel and haiku_devel (albeit in the iso) but the compiler can’t find the stdlib headers, which I don’t see in the tracker either - is there a guide for a standard setup just for userspace applications? It’s all changed since I last was writing stuff in 2010!!!
Should rerunning an original jam command, such as the example jam -q -j2 @nightly-anyboot from the docs, over the sources be all that’s required to pull in any changes? It seems to be a bit sporadic if my modifications to source files are detected and the files are recompiled, and/or if these are then included in the generated image. For a while I was seeing the changed file being recompiled in the output, but then, booting the image didn’t show any changes to the behaviour, even when the image’s checksum had been altered. Meanwhile I just switched to make the anyboot instead of the raw image, and a whole load of errors have come up, that should also have appeared for the raw image. I admit I haven’t really RTFM for jam yet, but I was hoping to get my feet a bit wet first as there’s wuite a lot of info to take in - I’m on Ubuntu ATM by the way, in case that’s relevant. IT has seemed that sometimes errors come and go away if I just rerun the build command so I don’t know if it’s a problem on the host side/toolchain cross-compatibilities in that setup.
Thanks for any help and sorry if these are basic things I should have found by google !
Ah, brilliant, that’s just what I was going to look into tomorrow!
Default Haiku installation include all necessary packages to compile Haiku C++ programs.
Do you know what I’m missing then that isn’t allowing the compiler to see the headers? I don’t seem to remember having to do anything in particular from the pre-package management days.
Did you reboot after the update/install? Some packages gets only activated after reboot.
I can think only this as a culprit, because we would know about problems like this, but i can’t recall bugreports like yours.
In fact, since the handling of %zu is inside the implementation of printf, which we could change, even for gcc2. But as it was replied by others we have defined our own macro for this (and for several other types).
Yes, running jam will build a new image with all your changes.
If you are on a 32bit system, gcc, gcc_syslibs_devel and haiku_devel are for gcc2. If you want to use gcc8 (since you mention setarch, I guess that is your case) you need instead gcc_x86; gcc_syslib_x86_devel and haiku_x86_devel.
If you think this is all too complicated and you don’t care about gcc2, you should install the 64bit version of Haiku instead. Then there will be no gcc2, no setarch, and no confusing _x86 in package names.
Okay cool, I’m guessing then it was just as I couldn’t reboot; stdio.h didn’t show up anywhere under /boot. I’ve been building for x86_64 so I just grabbed the 32-bit anyboot whilst I waited to try the old GCC and see what it supported, so I didn’t bother installing.
That was partially what I was thinking, so the reasons for the old compiler (please correct me if I’m wrong) are
the ABI has changed so whilst new software could be compiled against this, BeOS R5 binaries would be unable to e.g. call into libraries
the interface of any libraries needs to be kept/available as it was at that time, effecting both BeOS and newer software compiled against this.
So, where do we stand on adding newer functionality to the compiler/support libs? I’m guessing a backport of a new GCC to the old ABI would have been done already if it were possible/feasible, and similarly trying to enable something like C++11 on GCC2 would probably be a huge task, but is there a sort-of specification as to what we’re targeting and what can be added or modified? For example, I was looking at the 2.95 support table documented by GNU for what C99 features had been implemented as of that release, so I guess, whether or not it’s documented, I’m kinda wondering if Haiku’s GCC2 and runtimes have their own table of implemented features etc., at least theoretically. Then presumably, any code common to all architectures would need to target the featureset supported by that table, as well as what doesn’t break a newer GCC set to the appropriate standards version. Am I making sense?
I’ll keep an eye on my jam in the meantime, I think something a bit funky was happening but I didn’t write down the details at the time.
Yes, sorry, to clarify, I was generally asking about the sources for Haiku itself; the last bit was just if I’d missed something in getting a working compiler/header setup within the (32-bit) VM.
Based on the title of your topic, follow the recent ISO C18 and C++20 official specs.
GCC 2.95.3 is no longer “maintained” on Haiku - so just use the GCC 8.x-compatible build environments (Haiku’s x86_64, or the 32-bit x86 2nd build architecture).
No one was interested enough in doing it, that’s all.
When we started the project in 2001, gcc2 was still a reasonably recent compiler so it was fine. And we just went along with it for the next 20 years and now it is very much obsolete.
There have been some patches here and there to fix the most annoying issues. In some cases we resort to workarounds in the sourcecode, for example to declare private symbols for gcc2 we have to use some inline assembler macros, where for newer gcc we just use __attribute__((visibility)). In some other cases we made some updates to libstdc++ and to the C library. In a few very limited cases we also patched gcc2 itself (for example to have some limited support for wchar_t).
If someone is willing to do the work on having modern gcc or clang be able to generate libs with the old ABI, that would be great. However, the long term plan currently is to eventually drop compatibility with BeOS (we can’t really keep it forever?) so we just didn’t worry too much about it. But then again, if someone does this work, it makes it possible for us to have BeOS compatibility for a longer time.
Adding a new ABI to Clang would be less work than GCC indeed. Actually I think someone said that Clang has (or previously had) a partial implementation of the GCC2 ABI.
Yes, Apple partially implemented it already because they needed it for their IO Kit (a C++ API to their kernel, if I remember correctly). However they have not maintained this since the move to 64bit systems.
LLVM doesn’t maintain a stable C++ API either. If it relies on LLVM 3.9 it’s not hopeful. LLVM 11 is unlikely to be compatible. Only the C API is maintained as stable and it is rudimentary.
There is some support in gcc2 but it uses a different syntax (dllexport/dllimport) and I’m not sure how much of it can be used outside of building for Windows with PE object files.
- I’m on Ubuntu ATM by the way, in case that’s relevant. IT has seemed that sometimes errors come and go away if I just rerun the build command so I don’t know if it’s a problem on the host side/toolchain cross-compatibilities in that setup.
!