I downloaded an OpenBSD install disc but don't have time to install and play around for a few days.
So based on this, while we could invoke gcc if it happens to be present, it's unlikely and we should just use egcc instead of gcc. And if both gcc and egcc are present, we should prefer egcc anyway even if we do check for both names.ibara wrote:On OpenBSD, this compiler happens to be named egcc, as to not conflict with some architectures that have not or cannot make the switch to the LLVM toolchain (the Motorola 88000 architecture comes to mind as one such cannot), which then have an in-base compiler named gcc.
(fbc also uses the GCC envvar if present to find gcc).
Regarding forcing att syntax to be used: I assume this is because fbc by default uses the system as, which doesn't support intel syntax. On FreeBSD, there was exactly the same problem. Must be the case in all other BSDs. My solution for FreeBSD is this patch (not merged in yet, since I wandered off without finishing the FreeBSD crt headers).
On the subject of the missing CRT headers, dkl has already created a system for automatically generating the headers for all OSes recognised by FB, including OpenBSD: fbbindings. I don't think any of those inc/crt/ headers are actually used yet, though. FB's CRT/system headers are disorganised. And because each OS organises its headers differently (and especially the ways in which they include each other), it doesn't appear that their organisation is something that can be done fully automatically.
Missing crt headers has been a pain everywhere - headers for even basic C or Unix functions aren't actually complete on any OS, though they're by far the most complete for Windows, and completely absent for all Unices aside from Linux. So far, as a temporary fix, I've just been manually vreating a few critical headers by hand for Linux, Android, Mac, and FreeBSD, with help from fbfrog. I never got that merged in, because I wasn't happy with my way of doing it manually.