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