This is the mail archive of the crossgcc@sourceware.org mailing list for the crossgcc project.

See the CrossGCC FAQ for lots more information.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: portable build of eglibc


Am 12.02.2011 um 21:02 schrieb Enrico Weigelt:
> * Titus von Boxberg <titus@v9g.de> wrote:
>> Am 11.02.2011 um 20:24 schrieb Enrico Weigelt:
>> 
>>> * Titus von Boxberg <titus@v9g.de> wrote:
>>> 
>>>> All patches are only for the host tools.
>>> 
>>> Are you sure you with the absolute include pathes ?
>> 
>> In what sense could/should I be unsure?
> 
> Perhaps because absolute pathes are installation specific ?
The chance that some other BSD guy exists who wants to use ct-ng/eglibc
AND at the same time indulges in installing software in
nonstandard locations seems to me very small.
Should such a guy exist and post a question why he is
unable to build eglibc I'd direct him to the patch and
also recommend fancy new colours for the bicycle shed.

Furthermore, I doubt that if you moved some of your
libraries to /anicepath/lib you would be able to build
a lot with ct-ng.

All patches are admittedly of no better quality than the original software.
The necessity for four of the five patches (all but maybe patching away strpncpy)
is for me a sign of a build system not elaborated/portable enough and not
too well structured software (why privately declare strpcpy?
Why create private declarations like in types.h?). As far as I dug
into the software, I regard the way the host tools get
built as a q&d hack.

Thus, these patches are only for ct-ng, and only for existing
eglibc versions. And for that purpose I regard them as sufficient
because they do exactly what they are intended for, and do not worsen anything.
If I'd like to cure the root cause of the problems,
I'd dig deeper and send mail to the eglibc patches
mailing list. But for the time being that's a task I'm inclined
to burden the following generations of eager young software developers with ;-)

I also think that rpcgen and zic, as well as the prerequisites
I introduced in the patches, are no software parts that are under heavy
change. Thus, I could imagine that although the original software
and the patches can well be doubted they might be valid for a long time.

Regards
Titus


--
For unsubscribe information see http://sourceware.org/lists.html#faq


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]