Re: build failure when system does not provide MB_CUR_MAX

[Mike Frysinger]

On Tuesday 26 May 2009 18:40:23 Bruno Haible wrote:
> Mike Frysinger wrote:
> > i dont see any checks/replacements for when MB_CUR_MAX does not exist
>
> This is because MB_CUR_MAX is part of ANSI C + amendment 1 (ca. 1995), and
> no platforms are known that lack it (see
> gnulib/doc/posix-headers/stdlib.texi).
>
> Likewise for mbtowc(): It's present on all platforms we care about, see
> gnulib/doc/posix-functions/mbtowc.texi.
>
> > (like in a uClibc build where all multibyte
> > related stuff has been disabled).  for example, zile falls apart like so:
> > ../../zile-2.3.7/lib/mbrtowc.c: In function ‘rpl_mbrtowc’:
> > ../../zile-2.3.7/lib/mbrtowc.c:96: warning: implicit declaration of
> > function ‘mbtowc’ ../../zile-2.3.7/lib/mbrtowc.c:124: error: ‘MB_CUR_MAX’
> > undeclared (first use in this function)
>
> There is an easy way out: just don't disable all multibyte related stuff
> in uClibc.
>
> uClibc has this code, that's what you're saying. Therefore there's no point
> in gnulib to duplicate this functionality. All other platforms have
> ANSI C + amendment 1.

it's disabled explicitly because we dont want multibyte sucking up space on a 
system that doesnt need it.  there are a few packages (like zile) which dont 
currently have a way of disabling the multibyte workarounds.  i figured it'd 
be a two pronged approach: fix gnulib and fix zile.

you're saying this breakage is "by design" with gnulib, so that's that.
-mike

signature.asc
Description: This is a digitally signed message part.