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] |
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] |