[CT-NG 1.11.1] Error if libidn added to (e)glibc add-ons to build
Yann E. MORIN
yann.morin.1998@anciens.enib.fr
Wed May 18 16:42:00 GMT 2011
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
More information about the crossgcc
mailing list