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: [CT-NG 1.11.1] Error if libidn added to (e)glibc add-ons to build


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]