Crosstool-NG: WCHAR-support in uClibc-toolchain

[Freeed]

Hi!

I'm currently trying to migrate all my embedded projects to use
toolchains created by crosstool-ng (until now I use a variety of
different cross-toolchain buildsystems)

For a powerpc-based device I used the internal uClibc-toolchain of
buildroot (http://buildroot.uclibc.org/). While migrating to
crosstool-ng I stumbled upon wchar-support in the
crosstool-ng-generated uClibc-toolchain (buildroot moans, if some
settings differ from those in the external toolchain)

It is enabled in "scripts/build/libc/uClibc.sh" by default, if
C++-Compiler is selected. In my case, I want to disable wchar-support,
because I'm creating a tiny embedded system (until now I haven't
needed wchar in any application).

Therefore I would like to know, if it would be acceptable to insert
some extra options in the "C-library"-menu of crosstool-ng...just like
in buildroot:

-enable large file (files > 2 GB) support
-enable IPV6
-enable RPC
-enable toolchain locale/i18n support
-purge unwanted locales
-enable WCHAR support
-use software floating point by default
-enable stack protection support


Regards

Simon Pasch

--
For unsubscribe information see http://sourceware.org/lists.html#faq

[Yann E. MORIN]

Hello Simon!
Hello All!

On Wednesday 28 October 2009 12:37:35 Simon Pasch wrote:
> For a powerpc-based device I used the internal uClibc-toolchain of
> buildroot (http://buildroot.uclibc.org/). While migrating to
> crosstool-ng I stumbled upon wchar-support in the
> crosstool-ng-generated uClibc-toolchain (buildroot moans, if some
> settings differ from those in the external toolchain)

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).

> It is enabled in "scripts/build/libc/uClibc.sh" by default, if
> C++-Compiler is selected. In my case, I want to disable wchar-support,
> because I'm creating a tiny embedded system (until now I haven't
> needed wchar in any application).

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.

> Therefore I would like to know, if it would be acceptable to insert
> some extra options in the "C-library"-menu of crosstool-ng...just like
> in buildroot:

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. But OTOH, there's already an
option to enable/disable locales in uClibc.

So, I'm enclined to be careful here. Please, send a patch, and we'll discuss
it. Try to keep things well-contained, and send one patch per 'option', so
we can cherry-pick those that makes sense.

> -enable large file (files > 2 GB) support

Be carefull, option not needed if ARCH_64 (or the like).

> -enable IPV6
> -enable RPC

Let's see the amount of code this adds.

> -enable toolchain locale/i18n support

Already there, may need fixing.

> -purge unwanted locales

Depends on the above.

> -enable WCHAR support

Let's see the amount of code this adds.

> -use software floating point by default

Already there! :-)

> -enable stack protection support

Not uClibc-specific, if you add that, goes to the "C Compiler" menu.

In the end, I'd be glad to review your patches. Make it so that each new
feature is in a self-contained patch.

--
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| [phone] | Software  Designer | \ / CAMPAIGN     |  ___               |
| [phone] `------------.-------:  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

[Freeed]

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

> 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

[ct-ng-select-wchar-support-via-menuconfig.patch]

---

diff -Naur plain/crosstool-ng-1.5.1/config/libc/uClibc.in crosstool-ng-1.5.1/config/libc/uClibc.in
--- plain/crosstool-ng-1.5.1/config/libc/uClibc.in 2009-10-28 19:43:37.000000000 +0100
+++ crosstool-ng-1.5.1/config/libc/uClibc.in 2009-11-06 10:57:17.000000000 +0100
@@ -152,9 +152,19 @@
 
 config LIBC_UCLIBC_LOCALES
     bool
+    select LIBC_UCLIBC_WCHAR
     prompt "Add support for locales"
     default n
     help
       Say y if you want uClibc to support localisation.
 
       Note that seems to be broken on recent uClibc releases.
+
+config LIBC_UCLIBC_WCHAR
+    bool
+    prompt "Add support for WCHAR"
+    default n
+    help
+      Say y if you want uClibc to support WCHAR.
+
+      Maybe this is needed, if you're building a C++-Compiler
diff -Naur plain/crosstool-ng-1.5.1/scripts/build/libc/uClibc.sh crosstool-ng-1.5.1/scripts/build/libc/uClibc.sh
--- plain/crosstool-ng-1.5.1/scripts/build/libc/uClibc.sh 2009-10-28 19:43:37.000000000 +0100
+++ crosstool-ng-1.5.1/scripts/build/libc/uClibc.sh 2009-11-06 11:47:24.000000000 +0100
@@ -292,14 +292,23 @@
 ENDSED
     fi
 
+    # WCHAR support
+    if [ "${CT_LIBC_UCLIBC_WCHAR}" = "y" ] ; then
+       cat >>"${munge_file}" <<-ENDSED
+s/^.*UCLIBC_HAS_WCHAR.*/UCLIBC_HAS_WCHAR=y/
+ENDSED
+    else
+       cat >>"${munge_file}" <<-ENDSED
+s/^.*UCLIBC_HAS_WCHAR.*/UCLIBC_HAS_WCHAR=n/
+ENDSED
+    fi
+
     # Force on options needed for C++ if we'll be making a C++ compiler.
     # I'm not sure locales are a requirement for doing C++... Are they?
     if [ "${CT_CC_LANG_CXX}" = "y" ]; then
         cat >>"${munge_file}" <<-ENDSED
 s/^# DO_C99_MATH is not set/DO_C99_MATH=y/
 s/^# UCLIBC_CTOR_DTOR is not set/UCLIBC_CTOR_DTOR=y/
-# Add these three lines when doing C++?
-s/^# UCLIBC_HAS_WCHAR is not set/UCLIBC_HAS_WCHAR=y/
 #s/^# UCLIBC_HAS_LOCALE is not set/UCLIBC_HAS_LOCALE=y\\nUCLIBC_PREGENERATED_LOCALE_DATA=y\\n\\# UCLIBC_DOWNLOAD_PREGENERATED_LOCALE_DATA is not set\\n\\# UCLIBC_HAS_XLOCALE is not set/
 s/^# UCLIBC_HAS_GNU_GETOPT is not set/UCLIBC_HAS_GNU_GETOPT=y/
 ENDSED

---

--
For unsubscribe information see http://sourceware.org/lists.html#faq

[Yann E. MORIN]

Hello Simon!
Hello All!

On Friday 06 November 2009 15:41:26 Simon Pasch wrote:
> 2009/10/28 Yann E. MORIN <yann.morin.1998@...>:
> > 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

Yes, that's it! I stand corrected, thanks! :-)

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

I don't like it. It requires that the front-end ct-ng has intimate
knowledge of the components, and I don't like it. Also, it would first
require that the download+extract step be split from the rest of the
process, wich I don't much like either. In any case, this would require
a more generic action, smthg like "ct-ng libc-config", or even "ct-ng
cc-config", or "ct-ng balbla-config". As I said, I don't like it.

OTOH, I have to agree that there is some weirdness, a kind of chicken'n'egg
problem:
 - crosstool-NG requires the user to provide the config file
 - crosstool-NG handles the download only if this requirement is met
 - to create the config file, the user needs the source, which crosstool-NG
   downloads only if it already has a config file.

Yes, I know, this is weird, but I have yet no clean solution out-of-my-head.

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

Nice one, but could you follow the instruction for proper patch submission,
please? This is described in the "Contributing" section of the documentation:
http://ymorin.is-a-geek.org/hg/crosstool-ng/file/187e06178dcb/docs/overview.txt

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

Yes, that's the way to go. It's already done this way for other options.

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

Nope. Don't add hard-depdency on other components.

What we'd need in this case is smthg like, using prompt-less options:

in config/API.in (new file, let's find a better name):
 | config WCHAR_RQUIRED   # Or locales, or whatever...
 |   bool
 |   default n

in config/cc/gcc.in:
 | config CC_LANG_CXX
 |   prompt "C++"
 |   select WCHAR_REQUIRED

in config/libc/uClibc.in:
 | config LIBC_WCHAR_REQUIRED
 |   bool
 |   default y if WCHAR_REQUIRED
 |   select LIBC_UCLIBC_WCHAR

Et voila! When you choose "C++", it forces WCHAR support in uClibc, while
other C libraries are not forced to comply, while still allowing them to
use that, and at the same time it does not impose the gcc (and later other
compilers) to know about all C libraries.

But I think selecting wchar for C++ is not really needed without locales,
is it?

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

What defines are you refering to? If I read correctly, all munging of the
uClibc config file is already either:
 - required to shoe-horn our option into the config file (eg. arch, cpu...)
 - conditional on config option(s) (eg. locales, debug level...)

Regards,
Yann E. MORIN.

--
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| [phone] | Software  Designer | \ / CAMPAIGN     |  ___               |
| [phone] `------------.-------:  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

[Yann E. MORIN]

Simon,
All,

On Friday 06 November 2009 15:41:26 Simon Pasch wrote:
> With the attached patch I added a "enable/disable wchar" entry in
> ct-ng. That solves my problem for now...

Applied, thank you!
And sory for the delay...

Regards,
Yann E. MORIN.

--
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| [phone] | Software  Designer | \ / CAMPAIGN     |  ___               |
| [phone] `------------.-------:  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