[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/2.6.29.2; 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.
-mike
signature.asc
Description: This is a digitally signed message part.