[fpc-pascal] Nano-x

Michael Van Canneyt michael at freepascal.org
Thu Jul 20 13:46:52 CEST 2006



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

>> On Thu, 20 Jul 2006, Marco van de Voort wrote:
>>>> If you really believe that:
>>>> I suggest you start working on the sources in SVN then, because there are
>>>> _a lot_ of them.
>>>>
>>>> But I don't think that it should be done like that...
>>>
>>> Because?
>>
>> Because firstly I think that what initc does behind the scenes should not
>> be done in the first place,
>
> What, provide access to libc errno?

Yes.

>
>> and secondly because the argument of the varying
>> library name you have countered yourself with your implementation of link
>> aliases.
>
> I don't see that. Linkaliases are to provide the flexability to  override
> the default if that must be necessary after release. initc sets the default
> libc name for a certain platform. Two different things.

The difference is minor.

>
>> {$Linklib C} does just that: it links to the C library, i.e. makes available
>> some additional symbols. Initc also does some redirection of 'errno' handling
>> (be it the C or pascal version), which is totally uncalled for if you for
>> example need only sprintf()...
>
> If the two handlers for that aren't called, the whole stuff can be
> smartlinked out. No problem here.
>
>> It's a tough issue, and it's a matter of preference, I'd say, but personally,
>> I will not use initc as a rule...
>
> IMHO this was all already discussed in the unix reforms,

I'm not disputing your statement, but I have absolutely no recollection of this, 
and I followed the matter closely, as you well know.

> but as a detail it
> might have been forgotten. I don't like this backpedalling. Moreover IMHO
> there is no merit in the redundant $linklibs.
>
> Sooner or later sb will use a uclibc or msvcrt as basis for a headerset, and
> the redundant ifdeffing will begin.  Also there is the little issue for
> sometimes need {$linklib gcc}, we now haphazardly fixed for libgdb only. This
> kind of issues can also be changed centrally in initc.
>
> I'm afraid this kind of narrow thinking will in time result in the header
> sets working on the top 2 tier platforms, and constantly be out of date for
> the rest, simply because for each odd ball platform, it must be checked by
> the maintainer (that must then have all the libs to notice). Bad.

Please don't use terms as 'this kind of narrow thinking' which places
an element of emotionality in what is a purely technical discussion; 
It clouds people's judgement.

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.

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.

So, my conclusion is that we should take the following actions:

1. Finish the job in InitC, and make it truly a cross-platform unit.
    Currently it's full of ifdefs, this should be replaced with a
    platform-dependent initc.inc and a global, cross-platform initc.pp

2. Possibly extend it with some constants that describe properties of the libc in use.

3. Replace where possible and appropriate the {$linklib C} with a uses initc;

4. Put a section in the programmers's guide which describes the use of it,
    because it is rather important.

Michael.



More information about the fpc-pascal mailing list