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,

> AS for the third one, it might not be that complex after all. How
> many
> add-ons do exist, in the end? 4, 5 maybe? NPTL, LinuxThreads, ports,
> libidn, and localedef.
>
> It should be pretty easy to convert the string-config into a few
> booleans,
> add a few hidden bools that say if each add-on is internal or
> external, and
> tweak scripts/addToolVersion.sh to properly 'select' those hidden
> options,
> a bit like each version specify if LinuxThreads are supported.
> Eg. (choice ommitted for brevity):
>
>     config LIBC_GLIBC_V_2_9
>         bool "2.9"
>         select LIBC_GLIBC_ADDON_IDN_EXT # idn is external
>
>     config LIBC_GLIBC_V_2_10
>         bool "2.10"
>         # idn is internal
>
>     config LIBC_GLIBC_ADDON_IDN_EXT
>         bool
>         default n # Unneeded, 'n' *is* the default
>
>     config LIBC_GLIBC_ADDON_IDN
>         bool "Enable libidn"
>
> And so on, automatically. Then in the get/extract code, something
> like:
>     if [    "${CT_LIBC_GLIBC_ADDON_IDN}" = "y"     \
>          -a "${CT_LIBC_GLIBC_ADDON_IDN_EXT}" = "y" ]; then
>         GetOrExtract_it_for_gods_sake
>     fi
>
> The add-ons list would be:
>     local -a addons_list
>     local i j
>     if [ "${CT_LIBC_GLIBC_ADDON_IDN}" = "y" ]; then
>         addons_list+=( "libidn" )
>     fi
>     for i in "${addons_list[@]}"; do
>         printf "%c%s" "${j}" "${i}"
>         j="${separator}"
>     done
>
> That's a bit of work, but is really the best short- and mid-term
> solution,
> I believe, and probably long-term as well.
>
> Let's see what you guys think about it.

I agree with the general idea, but I think this implementation is more complex
than needed. We could simply keep using the existing CT_LIBC_ADDONS_LIST, even
for internal add-ons, add a hidden auto-config like:
    config LIBC_INTERNAL_ADDONS_LIST
        string
        default "libidn nptl" if LIBC_GLIBC_V_2_10
        default "nptl"        if LIBC_GLIBC_V_2_9 || LIBC_GLIBC_V_2_8
and so on, and create a new function to test if an add-on returned by
do_libc_add_ons_list() is internal.

What do you think?

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]