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] |
BenoÃt, All, On Wednesday 18 May 2011 17:20:18 BenoÃt THÃBAUDEAU wrote: > > 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? Hmm, right, not really needed. Agreed. > 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? Oh, right. Good point. Answering this question would also answer the case where libidn was an external addon and is now an internal one. > 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. I am not too fond of any solution either. I think the first one is the most easy and tenable option. Try downloading, [WARN] if not found (eg. "Add-on 'foo-bar' not downloaded. Maybe internal?"). Then at extract time, bail-out if add-on is not found in source tree and it's not internal (eg. "Add-on 'foo-bar' is not internal, and was not found (not downloaded)"). The second one, although probably the best in the long-term, is not really doable without much rework on the infra. I would prefer not to split the libc from its add-ons. 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. Regards, Yann E. MORIN. -- .-----------------.--------------------.------------------.--------------------. | Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: | | +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ | | +33 223 225 172 `------------.-------: X AGAINST | \e/ There is no | | http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. | '------------------------------^-------^------------------^--------------------' -- 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] |