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] eglibc internationalization support


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]