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