Re: Link failure with locale routines (when _MB_CAPABLE undefined)

[Corinna Vinschen <vinschen at redhat dot com>]

On Aug 18 15:29, Corinna Vinschen wrote:
> Hi Ulrich,
> 
> On Aug 18 14:02, Ulrich Weigand wrote:
> > Hello,
> > 
> > attempting to use the new locale routines, in particular newlocale
> > and freelocale, on a newlib built with _MB_CAPABLE undefined,
> > results in link failures:
> > 
> > spu/lib/libg.a(lib_a-newlocale.o): In function `_newlocale_r':
> > newlib/libc/locale/newlocale.c:113: undefined reference to `__C_locale'
> > newlib/libc/locale/newlocale.c:111: undefined reference to `__C_locale'
> > newlib/libc/locale/newlocale.c:167: undefined reference to `__loadlocale'
> > spu/lib/libg.a(lib_a-freelocale.o): In function `_freelocale_r':
> > newlib/libc/locale/freelocale.c:44: undefined reference to `__C_locale'
> > newlib/libc/locale/freelocale.c:44: undefined reference to `__C_locale'
> > 
> > This causes a build failure for libgfortran on spu-elf, because it
> > results in configure detecting uselocale available while newlocale
> > is not, and libgfortran doesn't handle that combination correctly.
> > 
> > The reason for the failure appears to be that __C_locale and
> > __loadlocale are defined only if _MB_CAPABLE is defined, but
> > they are used unconditionally from newlocale.c / freelocale.c.
> 
> Any chance for a patch?  You're set up for testing !_MB_CAPABLE
> after all...

The problem with !_MB_CAPABLE is that these targets don't support any
kind of locale settings at all and, so far, setlocale just returns the
fixed string "C". 

Thus it seems it doesn't make any sense to expose the POSIX-1.2008
locale functions to !_MB_CAPABLE targets at all, so I propose to disable
these functions and their prototypes unless #ifdef _MB_CAPABLE.

Thoughts?


Thanks,
Corinna

-- 
Corinna Vinschen
Cygwin Maintainer
Red Hat

Attachment: signature.asc
Description: PGP signature