[fpc-pascal] Nano-x

[Michael Van Canneyt]

On Thu, 20 Jul 2006, Marco van de Voort wrote:

>
> (snip water under the bridge)
>
>> As for your arguments:
>>
>> You are 100% right that it may be a good thing to have a central place which
>> somehow regulates access to libc; It will make things clearer and more
>> maintainable. However, if you want to position it like that, I do think
>> that it should be handled like that: The unit which provides the correct
>> glue to the C library, which we can say is the preferred way of linking
>> to the C library. I would even go as far as saying that in this case,
>> the program/library stub code can be placed in this unit. It would remove
>> a lot of code which is now in the compiler.
>
> What compiler code exactly do you mean? Cprt stuff?

Yes.

>
>> It should, however, not be positioned as the replacement of {$linklib C};
>> This decision should always be made by the programmer. It is up to us to
>> decide what to do with the units we distribute by default.
>
> That + the formal advise to do it that way, with the reasons I posted
> earlier is fine with me.
>
>> So, my conclusion is that we should take the following actions:
>
>> 2. Possibly extend it with some constants that describe properties of the
>> libc in use.
>
> Agree (also with the other points). However do you have examples of this?

At least 
- the name. 
- A constant describing whether errno is thread-safe etc.
- It is gnu libc. ? (with all it's peculiarities)
- Is libgcc linked in ?
- Does it provide threading by default ?
In short, stuff which might be important to know when dealing with libc...

Compare it to the t_systems records in the compiler.

Michael.