usage of {$FPC_USE_LIBC}

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

usage of {$FPC_USE_LIBC}

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?

TIA,
Marc

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: usage of {$FPC_USE_LIBC}

Michael Van Canneyt


On Mon, 17 Jul 2006, Marc Santhoff wrote:

> 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.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: usage of {$FPC_USE_LIBC}

Marc Santhoff
Am Montag, den 17.07.2006, 22:06 +0200 schrieb Michael Van Canneyt:

>
> On Mon, 17 Jul 2006, Marc Santhoff wrote:
>
> > 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


_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: usage of {$FPC_USE_LIBC}

Jonas Maebe-2
In reply to this post by Michael Van Canneyt

On 17 Jul 2006, at 22:06, Michael Van Canneyt wrote:

>> 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
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: usage of {$FPC_USE_LIBC}

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

I haven't tested this recently.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: usage of {$FPC_USE_LIBC}

Marco van de Voort
In reply to this 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).
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: usage of {$FPC_USE_LIBC}

Marc Santhoff
Am Dienstag, den 18.07.2006, 09:39 +0200 schrieb 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


_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: usage of {$FPC_USE_LIBC}

Marco van de Voort
> Am Dienstag, den 18.07.2006, 09:39 +0200 schrieb 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?

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

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: usage of {$FPC_USE_LIBC}

Marc Santhoff
Am Dienstag, den 18.07.2006, 15:42 +0200 schrieb Marco van de Voort:

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


>  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


_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: usage of {$FPC_USE_LIBC}

Marco van de Voort
> Am Dienstag, den 18.07.2006, 15:42 +0200 schrieb 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)

> >  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?
 
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: usage of {$FPC_USE_LIBC}

Marc Santhoff
Am Dienstag, den 18.07.2006, 21:34 +0200 schrieb Marco van de Voort:

> > Am Dienstag, den 18.07.2006, 15:42 +0200 schrieb 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.

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

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


_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal