Re: Crosstool-NG: WCHAR-support in uClibc-toolchain

["Yann E. MORIN" <yann dot morin dot 1998 at anciens dot enib dot fr>]

Hello Simon!
Hello All!

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