[fpc-devel] defines by the compiler... / linux, LIBC, SysCall

[Marco van de Voort]

Op 11-1-2024 om 15:48 schreef Martin Frb via fpc-devel:
>
> But neither LIBC nor HASUNIX are listed on that page.

I think LIBC as a define is a remnant of a 1.0.x era port and has no 
meaning in 2.0.

This is meanwhile all 20 years ago, so my memory might be a bit hazy 
(christmas 2003 and the half year after that), BUT HASUNIX was iirc 
meant to flag something for partially unixy targets, for which unit 
baseunix could be /mostly/ implemented, but unit unix not.  The only 
usage seems to be in link.pas around a USES baseunix, so I assume it 
means it has at least baseunix (but might not have unit unix or define 
"unix"). Possible candidates for such partial unixy targets are 
QNX,beos+variants and the libc netware ports.

FPC does use  a define FPC_USE_LIBC to switch the RTL to use library 
(libc, or libroot in old BEOS) rather than directly doing syscalls.

FPC_USE_LIBC was originally prepared because some 1.0.x era ports (sunos 
and beos) were libc ports by Carl.

I also used it to troubleshoot issues with the syscall RTL by linking it 
to libc and e.g. s/ktracing it. But then an year later Jonas used it for 
Darwin and massively cleaned it up, and that established it in a more 
permanet way. The way the define is set is a bit inconsistent though:

- The original concept and the way I've always used it as a cycle or 
snapshot (toplevel FPC "make all") options by setting OPT=-dFPC_USE_LIBC

- The targets openbsd and darwin set it in the RTL makefile and various 
ad-hoc looking ifdef/defines in packages/. Quite often using osdefs.inc. 
This is not really nice, as it prohibits the global switching between 
libc/syscalls that was the original idea. However probably the original 
concept was too difficult for targets where FPC_USE_LIBC was default, 
because you always had to pass the define in build commands or put it in 
fpc.cfg), and local workarounds were added.

Similarly I see hasunix defines in the makefiles too, while that is a 
target built-in. Odd.  Probably in the past it had more meaning.

>
> 1) I can add "uses SysCall".
> There is a comment this will work in 3.3.1 / not sure if 3.2.x will 
> abort compile, or just use some unit without the expected symbol.
>
> So the question is (for compilers starting at 3.2.0  // that is one 
> version back)
>
> - Can (on any linux/unix)  "uses SysCall" be compiled  (without error)

You can test that yourself on a Linux system by compiling a cycle with 
-dFPC_USE_LIBC and then compiling a test program (without defines)   
Since there was a bugfix necessary, I assume not.

> - Does it need to be guarded {$IFnDEF LIBC} ?

That define would be FPC_USE_LIBC.  But afaik that is only defined ad 
hoc on spots where it is needed during the FPC compilation. I.e. it is 
set in the build system rather than being a compiler built in. So no.

You can go two directions:

1 -dFPC_USE_LIBC is considered experimental for  Linux, and simply 
ignore it for old versions.

_OR_

2 for older versions, if the unit directly or indirectly uses packages 
that link to libc (like LCL and thus X11/GTK/QT) , I'd simply always use 
the libc declaration for older versions.