[CT-NG 1.11.1] eglibc internationalization support
Benoît THÉBAUDEAU
benoit.thebaudeau@advansee.com
Fri Jun 10 21:44:00 GMT 2011
Yann, all,
> The real reason we need localedef is to build locales, right? So
> maybe we'd better add an option:
> [ ] Build and install locales
>
> And then build localedef and locales. I mean, rather that list it in
> the
> add-ons list.
Yes, that's better, all the more eglibc-localedef does not really
behave like other add-ons.
> Below are a few quotes of your original patch:
>
> > +# This function builds and installs the C library locales
> > +do_eglibc_localedef() {
>
> Rename to 'do_libc_locales' and add the same function in the common
> glibc/eglibc script.
>
> Then, instead of calling do_eglibc_localedef conditionnaly on CT_LIBC
> ==
> eglibc, you can call it always. Then, once we know how to build
> locales
> for glibc, infrastructure is there.
OK. Is there the same kind of issue with uClibc, or is it specific to
(e)glibc?
> > + CT_DoStep INFO "Installing C library locales"
> > +
> > + mkdir -p "${CT_BUILD_DIR}/build-libc/localedef"
> > + cd "${CT_BUILD_DIR}/build-libc/localedef"
>
> Although localedef is part of the C library, its build procedure is
> really
> completely decorelated. Can't we build localedef in its own build
> dir:
> mkdir -p "${CT_BUILD_DIR}/build-localedef"
> cd "${CT_BUILD_DIR}/build-localedef"
>
> Or, is it required that it be built as a sub-dir of eglibc? Where are
> the
> locales definitions stored? Is that what --with-glibc= is for?
eglibc-localedef can probably be extracted and built outside of eglibc.
I have to check that. What is certain is that it uses at least
eglibc/localedata. I will do that if it is supported since that would
avoid disturbing the configuration of normal add-ons.
> > + CT_DoExecLog CFG
> > \
> > + "${src_dir}/configure"
> > \
> > + --prefix=/usr
> > \
> > + --cache-file="$(pwd)/config.cache"
> > \
> > + --with-glibc="${libc_src_dir}"
> > +
>
> Indeed, we do want to build localedef natively. It runs on the host.
> Correct?
Yes.
> Also, configure accepts --with-pkgversion and --with-bugurl, so we
> could
> add them as well if they are usefull, or add a comment stating they
> are
> not used for locales.
OK. I'll see if these options are put somewhere when building locales.
> Would it be worth having the localedef binary on the target, in case
> there
> is a need to build the locales on-the-fly there?
The native target localedef is already built and installed by (e)glibc,
so nothing to do here.
> > + # Set the localedef option for the target's uint32_t alignment
> > in
> > bytes
> > + localedef_opts+=(--uint32-align=4)
>
> Even on 64-bit archs?
I'll check.
> > @@ -19,6 +20,11 @@ do_libc_start_files() {
> > + case "$(do_libc_add_ons_list ,)" in
> > + "") extra_config+=("--enable-add-ons=no");;
> > + *)
> > extra_config+=("--enable-add-ons=$(do_libc_add_ons_list ,)");;
> > + esac
> > +
>
> ...and...
>
> > @@ -185,7 +191,7 @@ do_libc() {
> > case "$(do_libc_add_ons_list ,)" in
> > - "") ;;
> > + "") extra_config+=("--enable-add-ons=no");;
> > *)
> > extra_config+=("--enable-add-ons=$(do_libc_add_ons_list
> > ,)");;
> > esac
>
> ... -> Could you make those two hunks (and related) into a separate
> patch, please?
OK. Do you know if add-ons can be skipped in the do_libc_start_files()
step? Perhaps "--enable-add-ons=no" would be fine in all cases at this
step. That would save some configure time. On the other hand, it may be
too risky for the future maintainability.
Add-ons can also be auto-detected (it's the default). Do you think it
would be worth adding a way to choose "all" add-ons in the config? Note
that this can already be achieved by adding "--enable-add-ons" to the
_EXTRA_CONFIG_ARRAY.
> > > I have briefly looked at glibc's and eglibc's Makefiles. Both
> > > have a
> > > localedata/install-locales target, but apparently only for native
> > > builds
> > > since they use the built localedef. A host localedef is required
> > > in
> > > order
> > > to install the locales, hence eglibc's localedef add-on.
> > > Unfortunately,
> > > there doesn't seem to be such an add-on for glibc.
>
> Sad...
>
> > > The options for eglibc are:
> > > 1) Use the localedef add-on.
> > > 2) Use a pre-installed host version of localedef.
>
> 1) as you did. We'll be needing it on hosts that do not have it (
> yes,
> there are guys using uClibc-based desktops out there... ;-) )
OK.
> > > The options for glibc are:
> > > 1) Use eglibc's localedef add-on if it works, but it's probably
> > > better to
> > > avoid mixing packages.
>
> That's not an option, indeed.
>
> > > 2) Use a pre-installed host version of localedef.
> > > 3) Do not support installing target locales, which would be a
> > > shame.
>
> 3) is better in the short term. We can see later if we can devise a
> plan
> to build them.
OK. It would perhaps be feasible to extract/configure/build glibc
somewhere else for native host, which would build the native host
localedef. A restricted build like 'make [...] locale/localedef'
might also work after the configure. Overkill?
> > > I think 2) would be the best for both since it would avoid
> > > eglibc/glibc
> > > branches. The host localedef would be detected by CT-NG's
> > > configure.
>
> The issue is about people who are building on hosts that may not have
> have a localedef, for example uClibc-based desktops, on maybe MacOS.
OK.
> > > Do you think the installation of locales should be mandatory, or
> > > a
> > > config
> > > option?
>
> Config option, default n.
>
> > > Do you think that the list of locales to install should be a
> > > configuration,
> > > or that all locales should be installed?
>
> All locales. It would be up to the rootfs build system to choose what
> locales to install. So maybe we could add a script that accepts a
> list
> of locales, a destination rootfs, and copies required locales, and
> handling patterns, a bit like:
> tuple-locales --dest-dir /some/place/rootfs 'en_US*' fr_FR.UTF8
>
> Optionally, it should be possible to pass a file that lists such
> patterns:
> tuple-locales -d /some/place/rootfs -f my-locales-patterns
>
> It may even makes sense to add this option to populate.
> I can take care of that at a later stage...
OK.
> > > Tools like BuildRoot have an option to purge the target locales
> > > installed
> > > from a toolchain, so too many config options concerning locales
> > > is
> > > perhaps
> > > useless for CT-NG.
>
> Yes, indeed, it should be the role of such a build system to install
> needed locales.
>
> Sorry for the time it took for me to answer... Plus, I'm off for the
> WE
> starting tomorrow morning early, although I may have a bit of time to
> read emails at some point...
No problem. I just feared my previous message got forgotten in traffic.
I'll cook a new patch series when I have some time.
Best regards,
Benoît
--
For unsubscribe information see http://sourceware.org/lists.html#faq
More information about the crossgcc
mailing list