Crosstool-NG: WCHAR-support in uClibc-toolchain

Simon Pasch fpasch@googlemail.com
Fri Nov 6 14:41:00 GMT 2009


2009/10/28 Yann E. MORIN <yann.morin.1998@anciens.enib.fr>:

> Yes, this is a known 'issue'. There is a kind of plan to have buildroot
> rely on crosstool-NG to build its toolchain, so we'd end up with the
> same issue, and the idea was to make crosstol-NG expose its configuration
> so buildroot can act accordingly (enable/disable things).

Ah, okay...I saw Thomas Petazzoni's patches to better support external
toolchains. Buildroot currently only checks, if some values of the
uclibc-configuration from the crosstool-ng toolchain differs from the
values in buildroot-configuration.
( http://git.buildroot.net/buildroot/commit/?id=9456b58a8b3b4efdd8038a68370acf618aa9465b
)

So, in a next step buildroot would have to not only check those
values, but read them into its own configuration...but this is
buildroot-related stuff.


> As far as I remember, the g++ would not build if wchar was missing in the
> C library. But things may have changed, and this may work now. YMMV.

I'm fairly inexperienced in toolchain-creation, but I successfully
build several uclibc-toolchains with g++ (i386, powerpc) without wchar
(and locales-support). So it seems to be unneeded nowadays ;)

although, wchar is required for locales support:
http://git.buildroot.net/buildroot/commit/?id=27ce942e6536174a9fa6f5dd13f87d52bca0950c


> The uClibc config file is there for a purpose: so the user can set options.
> I would rather not duplicate the config menu from uClibc, and leave up to
> the user to give an appropriate config file.

Something like "ct-ng uclibc-menuconfig" would be very useful in that case...


> But OTOH, there's already an option to enable/disable locales in uClibc.

With the attached patch I added a "enable/disable wchar" entry in
ct-ng. That solves my problem for now...

...as I'm using buildroot, I've done it the buildroot-way (take a
uclibc-configuration and override some values important for other
packages)

I think this would be a good solution for ct-ng too. Take a
uclibc-configuration and override values, important for other parts of
the toolchain-creation via kconfig-select. In this scenario it's
transparent for the user, what settings are used in the resulting
toolchain, as it is all defined via menuconfig.

So, if wchar would be needed by c++ the following patch would be
sufficient, to select wchar.

diff -Naur plain/crosstool-ng-1.5.1/config/cc.in crosstool-ng-1.5.1/config/cc.in
--- plain/crosstool-ng-1.5.1/config/cc.in	2009-10-28 19:43:37.000000000 +0100
+++ crosstool-ng-1.5.1/config/cc.in	2009-11-06 15:15:23.000000000 +0100
@@ -35,6 +35,7 @@
     prompt "C++"
     default n
     depends on CC_SUPPORT_CXX
+    select LIBC_UCLIBC_WCHAR if (LIBC_uClibc)
     help
       Enable building a C++ compiler.


What do you think about making those hardcoded defines in
scripts/build/libc/uClibc.sh visible in menuconfig in the next step?

regards

Simon Pasch
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ct-ng-select-wchar-support-via-menuconfig.patch
Type: text/x-patch
Size: 2054 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/crossgcc/attachments/20091106/14436988/attachment.bin>
-------------- next part --------------
--
For unsubscribe information see http://sourceware.org/lists.html#faq


More information about the crossgcc mailing list