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] |
Yann, all, > At the time I did this code, only glibc was supported, and libidn was > an > external addon. OK. > Until glibc-2.10, libidn was an external addon. OK. > [--SNIP--] > > --- > > - # NPTL addon is not to be extracted, in any case > > - [ "${addon}" = "nptl" ] && continue || true > > + # Built-in addons are not to be extracted, in any case > > + [ -d "${addon}" ] && continue || true > > That's what I'd go with. OK. > Except that sometime, the addon dir is suffixed with the glibc > version, > so we should also check "${addon}-${CT_LIBC_VERSION}" Even for built-in add-ons? > Also, this construct is ugly (yes, I wrote it!), and not instantly > understandable, even if perfectly valid. The fact that set -e is in > effect should not entice us to work it around by writing obscur and > bad code, but really to write clean and lean code. set -e is here > to catch unexpected errors, not to complexify the code. > > I'll go do penance. Consider I've been properly chastised. > > We should either use a real if-then-fi, or a simpler test, such as: > [ ! -d "bla" -a ! -d "bla-bla" ] || continue > > I prefer the if-then-fi here. Care to address that in the process, > please? Yes. > In fact, when extractions are forced, the full source dir is removed, > so the extracted file stamps are removed, so the whole libc dir is > removed, so upon the next extraction, libc will be totally extracted > again, addons-included. > > Crosstool-NG, it rocks with poneys! ;-) Perfect. You have omitted to answer the 2nd part of my comment concerning this solution. In do_libc_get(), the glibc script uses the same kind of test to determine whether it has to download a tarball for each add-on. Replacing this test with the suggestion above is not possible since the glibc has not yet been extracted when this function is invoked. So what do you suggest for that? I see the following solutions: - Try to download all selected add-ons as if they were external, then do not abort if the download fails. I don't like it since it would not be possible to differentiate built-in add-ons that can't be downloaded from real download failures. - Extract glibc before downloading the add-ons so that "-d" can be tested. Mixing up the download and extract steps in this way would affect the infrastructure. - Create and use a list of the built-in add-ons for each version of (e)glibc. That would have to be maintained each time support is added for a new version of (e)glibc. > Thanks for the report. Care to send a proper patch with your SoB? Yes, once you have answered my questions above. Should I create the patch against 1.11.1 or against HEAD? Regards, BenoÃt -- 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] |