Is this page up to date?
https://www.freepascal.org/docs-html/prog/progap7.html

Maybe I am wrong, but looking at the tsysteminfo does the value in extradefines specify values that will be defined during compilation (such as those given on that page)?

If the do then "sunos" has
             extradefines : 'UNIX;LIBC;SUNOS;HASUNIX';

But neither LIBC nor HASUNIX are listed on that page.

-------
I don't have sunos for testing.
But https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues/40575

The primary target is to avoid compilation errors.

All the below guarded by {$ifdef linux}

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   // that is one version back)

- Can (on any linux/unix)  "uses SysCall" be compiled  (without error)
- Does it need to be guarded {$IFnDEF LIBC} ?

2) If it can always be used, I can then check
  {$IF declared(Do_SysCall)}

3) If Do_SysCall is not avail
Does FPC then provide the define LIBC?

So could I do
  {$IF declared(Do_SysCall)}
     // code uses Do_SysCall
  {$ELSE}
    {$IFDEF LIBC}
       // code imports ptrace from libc
    {$ELSE}
      // code defines empty dummy "raise Exception.create('not supported');"
      // compiles, but wont work
    {$ENDIF}
  {$ENDIF}

Thanks for any help/feedback.

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.

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.

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 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)

Sure?

-dFPC_USE_LIBC    would be specified be the user or Makefile when the fpc/rtl is build.

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?)

--------------------------

I have 2 different concerns

1) What happens on sunos?
(Where the compiler defaults to LIBC)

That is the case I wont to cover.

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

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)

-----------------------------
as for point 1
To make sure it compiles with
- normal build fpc on linux/darwin
- normal build fpc on sunos

{$ifdef linux}
   uses   SysCall;
{$endif}
{$ifdef darwin}
   {$DEFINE FPDEBUG_USE_LIBC}  // darwin: always libc
{$else}
   {$IF not declared(Do_SysCall)}  // Linux, but no Do_SysCall

    {$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

Op 11-1-2024 om 16:56 schreef Martin Frb via fpc-devel:

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 :-)

Yes. Inside the FPC build process. And is always undefined outside of it.

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

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?

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.

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.

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 ?

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.

Ok, kind of expected that

Ok. ...

Now what I was hoping for, but....

- Darwin isn't a problem. As I test for that anyway.
- I can add {$IFDEF SUNOS} too
- Not sure which others...

Sadly however the list can change. So without "LIBC" or other such define, this is going to be tricky....