[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: build failure when system does not provide MB_CUR_MAX

From: Mike Frysinger
Subject: Re: build failure when system does not provide MB_CUR_MAX
Date: Tue, 26 May 2009 18:46:45 -0400
User-agent: KMail/1.11.3 (Linux/; KDE/4.2.3; x86_64; ; )

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.

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]