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] |
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] |