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.
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
