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