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.
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
