Hi,

I read http://www.freepascal.org/wiki/index.php/OS_aware_RTL

and wonder when {$FPC_USE_LIBC} is set and how the decision is made?

TIA,
Marc

In the Makefile.fpc for the platform. It's added to the compiler options.

Michael.

So it's off by default, because only Darwin and Solaris define it.

Thanks,
Marc

And if you meant "how we made the decision": it's only done by default for Darwin, because there libc is the only supported system interface, for "netware libc" (libc is the recommended netware system interface, but we also have a non-libc dependent netware port) and for solaris (less porting work than implementing full syscall support).

You can enable it for most (all?) *nix'es by compiling the rtl with OPT="-dFPC_USE_LIBC"

Jonas

You can enable it for most (all?) *nix'es by compiling the rtl with OPT="-dFPC_USE_LIBC"

I haven't tested this recently.

I read http://www.freepascal.org/wiki/index.php/OS_aware_RTL and wonder when {$FPC_USE_LIBC} is set and how the decision is made?

For *nix the main advantage of syscalls is that the avg small binary holds better in time, not in the least the compiler itself. Also crosscompiling these basic binaries doesn't require the libraries of the target. I recently cleanup a system that was constantly upgraded, and found '98-'99 FPC binaries that were still working on Sarge.

For large binaries using lots of libraries (like lazarus) it is less useful, since they link to libc anyway.

Note that using libc has some advantages too, I list some in http://www.stack.nl/~marcov/unixrtl.pdf which was the original design doc for the Unix reform. The most commonly expected one, a size advantage is not true however. FPC syscall binaries are smaller than their corresponding libc linked one. This probably because dynlinking forces some rather large tables into the binary, and the actual syscall using code is very small.

The decision to base Darwin on libc was Jonas'. It seems to work, but there was never a competing syscall solution (that might also have worked).

Marco van de Voort wrote

Note that using libc has some advantages too, I list some in http://www.stack.nl/~marcov/unixrtl.pdf which was the original design doc for the Unix reform.

I read this and browsed the source back and forth and to be honest I'm more confused than before. ;)

Let's make it specific:

If I want to add a missing function from libc to the right unit, how would I?

Do I have to fiddle with what's called "assembler aliasing" in any way or do I declare as "external libc"?

How do I find the right unit or include file to stick it in?

I'm talking about the function "readdir_r" existing at least on bsd's and on newer linux.

(btw. the wiki has improved very much in this area, good work)

Regards,
Marc

Research if it is standarised, and doable on a syscall level. If not it can only go to unit libc (but that is Michael's terrain), which is Linux/i386 specific.

*dir functions are special. These are (3) functions and are done by an own probably not 100% compat implementation in syscall ports. Why would you want to do this?

I'll go looking there, thanks.

... has this changed recently? I looked at almost any file having "syscall" in it's name but didn't find anything regarding "*dir". I forgot to mention that I'm using fpc 2.0.2 release sources atm.

Why would you want to do this?

Because "readdir_r" gives proper error messages and "readdir" doesn't.

But you're right, for testing it's functionality I could link to libc directly from my code.

Marc

Did you grep?

For linux they are in linux/ossysc.inc,
prefix by fp as per baseunix convention (fpreaddir,fpopendir)

> Why would you want > to do this? Because "readdir_r" gives proper error messages and "readdir" doesn't.

Depends on implementation, but actually I meant: why are you not using findfirst/findnext which is portable?

Yes, but with a wrong pattern - found them now.

Because that's my target. I'm trying to make an experimental new (sysutils.)FindFirst/-Next implementation with detailed error messages.

But first I have to review the *dir function implementations, up to now I assumed the libc functions would be used ... and my first finding is: there are the aliases defined that get resolved in the function and procedure declarations in bunxh.inc.

Thank you,
Marc