Fix and enable building FreeBASIC for Darwin / Apple Silicon

[agorangetek]

Fix and enable building FreeBASIC for Darwin / Apple Silicon

Upstream publishes no macOS binaries of any version (the SourceForge
Binaries-* folders only ever contain DOS, Windows, Linux, FreeBSD and
Raspberry Pi packages), so fbc can currently only be obtained on macOS by
bootstrapping it by hand — and that fails, because the Darwin support has
bit-rotted against modern ld64 and against arm64. This branch makes a native
darwin-aarch64 build work end to end.

I bootstrapped from the official FreeBASIC-1.10.1-source-bootstrap package
(its linux-aarch64 compiler C sources are the closest CPU family; they are
self-contained C with no #includes) plus a libfb built natively from the
100%-C runtime sources, and then built current master with it. Getting there
needed the fixes below.

Commits

1. darwin: define DISABLE_OPENGL when X11/XQuartz is unavailable —
   gfx_opengl.c still calls fb_hGL_GetProcAddress(), which only the X11
   driver defines; without XQuartz libfbgfx.a has an undefined symbol and
   every link fails. The stub for this already exists, it just was not
   selected.

2. rtl-error: don't emit an indirect jump when RESUME support is off —
   rtlErrorCheck()/rtlErrorThrow() pass a resume label only when -ex/-exx
   enabled RESUME support; without it fb_ErrorThrowAt() can never return a
   usable jump target, so the goto *result is dead. Emitting a plain call
   instead is equivalent and additionally keeps the generated C acceptable to
   clang, which rejects goto *ptr in a function with no address-of-label
   expression. -ex/-exx code is unchanged.

3. darwin: align DATA descriptors to the pointer size — DATA tables are
   { short, void* } packed, so the embedded pointers are 2-byte aligned.
   ELF tolerates that, ld64 does not: ld: pointer not aligned in '_label$N'+0x16, a hard error on arm64. Darwin now gets the naturally
   aligned descriptor (16 bytes); other targets keep the packed layout.

4. darwin: use the correct arm64 va_list ABI — Apple's arm64 va_list
   is a plain pointer (sizeof(va_list) == 8), not the AAPCS64
   __va_list_tag struct; cva_start()/cva_arg() read garbage and any
   cva_list program crashed.

5. profile_cycles: handle Mach-O sections — Mach-O has no
   __start_/__stop_ symbols and 16-character section names, so the ELF
   section scan cannot work; guard it for Darwin and degrade to an empty
   report instead of failing to build.

6. darwin: link through the C compiler driver instead of driving ld64 —
   the Darwin link line was a GNU ld line (crt1.o/crti.o/crtbegin.o,
   -macosx_version_min 10.4, --eh-frame-hdr, -lgcc, -shared -h<name>).
   ld64 rejects --eh-frame-hdr, the crt objects are not linkable that way on
   macOS, and libgcc does not exist unless a GCC toolchain is installed.
   Darwin now links via clang, which brings in the startup object and
   libSystem; -dylib maps to -dynamiclib -install_name, and -arch arm64
   is passed explicitly.

7. darwin: name shared libraries .dylib, and export their symbols —
   -dylib named its output .so on every unix target, including Darwin, where
   Mach-O calls it .dylib; .so is the loadable-bundle extension. It worked
   only because fb_DylibLoad() falls through to the .so entry in its
   candidate list. The link line also dropped --export-dynamic for Darwin
   rather than translating it, so -export did nothing there; it is now
   -Wl,-export_dynamic.

Validation

Built master (5714d10) natively for darwin-aarch64 on macOS 27 / Apple M5
with the Xcode 27 toolchain, then ran the upstream fbcunit suite
(make unit-tests, 2283 cases, -exx -mt):

 Asserts    Passed    Failed  Suite
1151707   1151705         2  Total

tests/unix-tty — which builds a library with -dylib and loads it back
through fb_DylibLoad() — could not be built on macOS at all before this
branch (tester.cxx needs C++17, which Apple clang does not default to, and
compares the Linux-only termios.c_line), so nothing exercised that path on
Darwin. It builds now, and its two dylibload testees pass on Apple silicon:

testee-dylibload-only-examplelib          123 hello hello hello
testee-dylibload-dylibfree-examplelib     123 hello hello hello

The whole suite passes with both C backends (Apple clang and GCC 16); the
two failing assertions are the same in both and are the only remaining issue I
know of:

optimizations/consteval.bas(63) : CU_ASSERT_DOUBLE_EQUAL(acos(-1.0f), acos(f), EPSILON_SNG)

which looks like a constant-folding vs. runtime-libm ULP difference rather
than an arm64 regression — I could not check it on other platforms, so please
treat it as unverified.

fbc also rebuilds itself with Apple clang alone (no GCC anywhere), and
rebuilds itself with GCC; both binaries behave identically on the suite.

Reproducing

brew install gcc                     # for the bootstrap only
make -C fbc-1.10.1 rtlib TARGET=aarch64-darwin CC=clang AR=ar AS=as
make -f bootstrap-build.mk           # pre-generated C + native libfb -> stage-1 fbc
cp build/fbc-stage1 fbc-1.10.1/bin/fbc
cd fbc
make rtlib gfxlib2 TARGET=aarch64-darwin CC=clang AR=ar AS=as
GCC=/opt/homebrew/bin/gcc-16 CLANG=/usr/bin/clang AS=/usr/bin/as AR=/usr/bin/ar \
  make compiler TARGET=aarch64-darwin CC=clang AR=ar AS=as \
       FBC="../fbc-1.10.1/bin/fbc -i $PWD/inc" || true
# stage 1 still has the old link logic, so link the first Darwin fbc by hand:
clang -o bin/fbc lib/freebasic/darwin-aarch64/fbrt0.o \
      src/compiler/obj/darwin-aarch64/*.o \
      -Llib/freebasic/darwin-aarch64 -lfb -lncurses -lm
# from here bin/fbc has the fixed linking and can rebuild itself:
make compiler TARGET_OS=darwin TARGET_ARCH=aarch64 CC=clang AR=ar AS=as FBC="bin/fbc -i inc"

Relationship to other pull requests

• The makefile change that normalizes arm64 to aarch64 is taken from
  Fix macOS arm64 (Apple Silicon) linker support #470 by @metaneutrons — thanks. It is the piece of that PR which makes a
  plain make work on Apple Silicon; without it uname -m's "arm64" is
  normalized to the 32-bit arm and everything lands in darwin-arm.
• Fix macOS arm64 (Apple Silicon) linker support #470 stops short of linking, which may be worth knowing before choosing
  between them: it does not touch the crt1.o lookup, and on current macOS
  that lookup cannot resolve (clang --sysroot=<sdk> -print-file-name=crt1.o
  returns the bare name, so hFindLib() reports error 23: File not found, crt1.o), leaving ld64 with no startup object:
  Undefined symbols for architecture arm64: "_main". It also predates the
  DATA descriptor alignment problem. Both are fixed here.
• Add support for Cocoa OpenGL screen in gfxlib2 and other compiler error fixes for macOS  #448 (Cocoa OpenGL) touches makefile, src/compiler/fbc.bas and
  src/rtlib/profile_cycles.c as well, so it will conflict with this branch.
  It is the better long-term answer for macOS graphics (no XQuartz needed);
  this branch only makes the existing X11/XQuartz path build and work. Happy
  to rebase on whichever lands first.