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]

[PATCH 0 of 5] libc internationalization support


Hi Yann, all,

This is a new revision of my patch series adding support for locales. I have
tested it successfully with eglibc and glibc 2.13.

The changes are:
 - It is updated against the latest CT-NG changes.
 - It takes your comments into account.
 - It adds partial support for glibc locales.
 - It fixes the extraction/patch step of Linaro GCC 2011.07 (related to the
   previous patch I sent).

As to the alignment of uint32_t on 64-bit targets, it is target-specific, but so
far, a 32-bit alignment should be fine for all supported targets, which seems to
be confirmed by:
http://cgit.openembedded.org/cgit.cgi/openembedded/tree/classes/libc-package.bbclass
However, I do not have access to all these targets to check that this is correct.

Concerning the support of glibc locales, it works by building the whole native
glibc for the host, then it uses the built localedef to build the locales. I
have tried a partial build limited to localedef, but it does not work because of
make dependencies with other parts of the libc.

As explained in the patch, there is a huge limitation for glibc: The host and
target endianness and uint32_t alignment must be the same for the locales to be
supported by the target. Hence, I'm not certain this patch is worth keeping.
It's better than nothing, but it is not helpful for half the targets.

Fixing this would require a patch for each version of glibc to make its
localedef more like eglibc's (i.e. supporting endianness and alignment options,
and with a Makefile allowing to pass extra options to localedef). Another
solution would be to build eglibc's localedef natively for the host, then to use
it to build glibc's locales, but this may lead to compatibility issues. Issues
like this one show that glibc is really not suited for cross-compiling, which is
eglibc's job.

Also note that by default, eglibc's install-locales generates separate locale
files while glibc's puts all locales into usr/lib/locale/locale-archive.
eglibc's way of doing this is easier to handle for tools like BuildRoot to
remove unwanted locales, but unwanted locales can also be removed from the
archive using localedef. For eglibc, we could use --add-to-archive to force the
creation of an archive to be more consistent with glibc, but it would be
preferable the other way around to use --no-archive with glibc. Unfortunately,
glibc's install-locales does not accept extra options to pass to localedef,
which could be solved by adding a small wrapper script, but I think it is not
worth it since this is not really an issue.

Best regards,
BenoÃt

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