Discussion:
[fpc-pascal] usage of {$FPC_USE_LIBC}
Marc Santhoff
2006-07-17 19:53:36 UTC
Permalink
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
Michael Van Canneyt
2006-07-17 20:06:23 UTC
Permalink
Post by Marc Santhoff
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?
In the Makefile.fpc for the platform. It's added to the compiler options.

Michael.
Jonas Maebe
2006-07-17 22:36:46 UTC
Permalink
Post by Michael Van Canneyt
Post by Marc Santhoff
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?
In the Makefile.fpc for the platform. It's added to the compiler options.
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
Marc Santhoff
2006-07-17 22:10:54 UTC
Permalink
Post by Michael Van Canneyt
Post by Marc Santhoff
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?
In the Makefile.fpc for the platform. It's added to the compiler options.
So it's off by default, because only Darwin and Solaris define it.

Thanks,
Marc
Marco van de Voort
2006-07-18 07:28:52 UTC
Permalink
Post by Jonas Maebe
You can enable it for most (all?) *nix'es by compiling the rtl with
OPT="-dFPC_USE_LIBC"
I haven't tested this recently.
Marco van de Voort
2006-07-18 07:39:21 UTC
Permalink
Post by Marc Santhoff
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).
Marc Santhoff
2006-07-18 13:15:26 UTC
Permalink
Post by Marco van de Voort
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
Marco van de Voort
2006-07-18 13:42:41 UTC
Permalink
Post by Marc Santhoff
Post by Marco van de Voort
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. ;)
If I want to add a missing function from libc to the right unit, how
would I?
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.
Post by Marc Santhoff
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.
*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?
Marc Santhoff
2006-07-18 14:48:11 UTC
Permalink
Post by Marco van de Voort
Post by Marc Santhoff
I'm talking about the function "readdir_r" existing at least on bsd's
and on newer linux.
*dir functions are special. These are (3) functions and are done by an own
probably not 100% compat implementation in syscall ports.
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.
Post by Marco van de Voort
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
Marco van de Voort
2006-07-18 19:34:14 UTC
Permalink
Post by Marc Santhoff
Post by Marco van de Voort
*dir functions are special. These are (3) functions and are done by an own
probably not 100% compat implementation in syscall ports.
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.
Did you grep?

For linux they are in linux/ossysc.inc,
prefix by fp as per baseunix convention (fpreaddir,fpopendir)
Post by Marc Santhoff
Post by Marco van de Voort
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?
Marc Santhoff
2006-07-18 20:27:10 UTC
Permalink
Post by Marco van de Voort
Post by Marc Santhoff
Post by Marco van de Voort
*dir functions are special. These are (3) functions and are done by an own
probably not 100% compat implementation in syscall ports.
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.
Did you grep?
Yes, but with a wrong pattern - found them now.
Post by Marco van de Voort
For linux they are in linux/ossysc.inc,
prefix by fp as per baseunix convention (fpreaddir,fpopendir)
Post by Marc Santhoff
Post by Marco van de Voort
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?
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

Loading...