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] |
Benoit, All, On Thursday 09 June 2011 15:42:07 BenoÃt THÃBAUDEAU wrote: > Does somebody have suggestions/comments/preferences or need more > time to answer, or should I propose a patch first, then discuss? 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. 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. > +  Â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? > +  Â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? 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. 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? > +  Â# Set the localedef option for the target's uint32_t alignment in > bytes > +  Âlocaledef_opts+=(--uint32-align=4) Even on 64-bit archs? > @@ -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? > > 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... ;-) ) > > 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. > > 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. > > 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... > > 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... 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] |