[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: Wed, 27 May 2009 02:58:41 -0400
User-agent: KMail/1.11.3 (Linux/; KDE/4.2.3; x86_64; ; )

On Wednesday 27 May 2009 01:18:26 Simon Josefsson wrote:
> Mike Frysinger writes:
> > On Tuesday 26 May 2009 19:13:51 Bruno Haible wrote:
> >> Mike Frysinger wrote:
> >> > 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.
> >>
> >> Do you think it will take less space if each of these packages had a
> >> copy of some gnulib-provided multibyte + locale code linked in
> >> _statically_, than when uClibc has it linked in _once_, in a shared
> >> library? I don't think so.
> >
> > i never said that.  the point was to fix these packages that require
> > multibyte so that they dont have any multibyte cruft either.
> I think that is a much better solution than making gnulib re-implement
> more of ANSI C multibyte stuff.  And if you do that work, the
> application won't need MB_CUR_MAX, will it?  So the problem is gone.

there was never a situation of fix this *or* that.  like i said earlier, the 
plan was to try and fix *all* relevant locations so that every possible 
package benefits.  it's faster to start threads in parallel after all.

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

reply via email to

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