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

[Marco van de Voort]

Op 11-1-2024 om 16:56 schreef Martin Frb via fpc-devel:
> On 11/01/2024 16:34, Marco van de Voort via fpc-devel wrote:
>>
>> Op 11-1-2024 om 15:48 schreef Martin Frb via fpc-devel:
>>> - 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.
>
> Not necessary. (as far as I understand the comments that had been made 
> already)
> -dFPC_USE_LIBC  would not change the os target to sunos.  And 
> therefore FPC would not look at the tsysteminfo 

Let me state it more clearly:

The point is that given a precompiled Linux RTL, to my best knowledge  
you can't test any define outside the FPC build environment to see if 
the RTL was compiled with FPC_USE_LIBC or not. Maybe there is some 
workaround testing for some symbol inside the system unit with{$if 
defined(symbol}, but there is no supported global define to test.

Targets that enable libc by default (darwin, sunos and openbsd 
apparently) by default make this work by locally enabling FPC_USE_LIBC, 
usually both in rtl/$target or by other hacks in various packages/ dirs 
for shared code, and simply not providing any alternative in the target 
specific code.

And to my best knowledge the "LIBC" in the extradefines of Slowaris 
(below) means zip, nada, zilch. It is an artifact of 1.0.x times, which 
is so old EVEN Lazarus doesn't support it :-)

> containing
>      extradefines : 'UNIX;LIBC;SUNOS;HASUNIX';
>
> -dFPC_USE_LIBC   would just affect the "uses SysCall" (and that 
> hopefully in *exactly* the same manner as compiling on sunos)
>
Yes. Inside the FPC build process. And is always undefined outside of it.
>>
>>> - 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.
>
> Sure?
>
> -dFPC_USE_LIBC    would be specified be the user or Makefile when the 
> fpc/rtl is build.

Yes. But the targets that default to it locally define it in RTL 
makefiles and $ifdef code. Not by means of compiler.

>
> But when an fpc (that had been build with -dFPC_USE_LIBC ) is used to 
> compile a random project, will then this fpc by tiself define 
> -dFPC_USE_LIBC    (without the user needing to do so?)
>
Not that I know. Which code does this according to you? The whole 
compiler/ dir doesn't grep on FPC_USE_LIBC so how would this happen?

> I have 2 different concerns
>
> 1) What happens on sunos?
> (Where the compiler defaults to LIBC)
>
> That is the case I wont to cover.

Currently the assumption is that you simply test for such targets and 
then define FPC_USE_LIBC yourself for where you need it.  Any additional 
testing of system or syscall with some $if defined would be nice, but 
beware of multiplatform concerns.

>
> 2) What happens, if the user "tampers" with settings building a non 
> default fpc.

If people do unsupported things they (and apparently you)  are f*scked.

>
> That 2nd part is not that important in respect to my questions in this 
> mail.
> If the user does that, then  (when compiling lazarus or any project)
> -  no special define may be set by FPC (and that is ok)
> - the user may have to set a define according to the project (lazarus 
> could offer a workaround define)
>
openbsd seems to use FPC_USE_SYSCALL as a workaround to override a 
locale FPC_USE_LIBC ( packages rtl-extra/bsd/osdefs.inc)

So openbsd locally defines FPC_USE_LIBC if "openbsd" is defined, but NOT 
if FPC_USE_SYSCALL is defined, while a hack, it has a certain symmetry.

> -----------------------------
> as for point 1
> To make sure it compiles with
> - normal build fpc on linux/darwin
> - normal build fpc on sunos
>
>
> {$ifdef linux}
or other "full"syscall  *nix ports like FreeBSD and NetBSD and OPENBSD 
with FPC_USE_SYSCALL.
>    uses   SysCall;
> {$endif}
> {$ifdef darwin}

or solaris or openbsd

>    {$DEFINE FPDEBUG_USE_LIBC}  // darwin: always libc
> {$else}
>    {$IF not declared(Do_SysCall)}  // Linux, but no Do_SysCall

But not if trunk ?

>
>      {$IFDEF LIBC}                    // Does this define ever exist (by fpc)
>        {$DEFINE FPDEBUG_USE_LIBC}     // no DoSysCall ==> use libc
>      {$ELSE}
>        {$DEFINE FPDEBUG_USE_DUMMY}  // no DoSysCall ==> empty dummy proc
>      {$ENDIF}
>
>    {$ENDIF}
>
>       // ELSE: Do_Syscall exists and can be used
> {$endif}
>
> Will that work?
> ==>> Will (on linux, including sunos)
>       "uses SysCall"
> compile (not throw an error during compilation). (that is for NORMAL / 
> non-tampered FPC)
>
> If yes, then that should work. (even if LIBC isn't defined)
> If yes, then I can check if "DoSysCall" can be used
>
I don't know. Needs testing on many targets and platforms.

IMHO:

- file a _really_, /really/ urgent bugreport/request to fix this in 
3.2.4 and onwards to define some symbol in system if FPC_USE_LIBC is 
defined and test that in trunk and 3.2.4 then test for that if 
fullversion>302040 or so.

- for older compilers (3.2.2, and 3.2.0 for a _very_ short time, since 
it is more than one version old if 3.2.4 is released) simply assume libc 
for darwin,linux,openbsd and ignore anything else if your application 
doesn't already link to libc anyway, or if you can find some symbol to 
$if defined() test.