[blfs-dev] Policy on locale for building ? (ticket #4745)
bruce.dubbs at gmail.com
Sat Mar 1 13:29:08 PST 2014
Ken Moffat wrote:
> Looking at #4745, there is a workaround for a problem building gegl
> when ruby has already been installed. Dunno why the originator
> hasn't actually put this in the wiki (I assume an ID for creating a
> ticket provides those privilege?), but there is an easier solution:
> If I configure gegl in my normal UTF-8 locale, there is no problem
> even with ruby already installed. But if I pass LC_ALL=C to
> configure, I get the reported problem during 'make' :
> ../tools/create-reference.rb:331:in `block (2 levels) in <main>':
> invalid byte sequence in US-ASCII (ArgumentError)
> from ../tools/create-reference.rb:325:in `foreach'
> from ../tools/create-reference.rb:325:in `block in <main>'
> from ../tools/create-reference.rb:318:in `times'
> from ../tools/create-reference.rb:318:in `<main>'
> Makefile:881: recipe for target 'api.html' failed
> make: *** [api.html] Error 1
> What I don't recall is whether we ever recommend building packages
> in BLFS using the C or POSIX locales ? My belief is that everyone
> ought to be using UTF-8 locales by now, but from support posts over
> the years I guess that some of our users are behind the curve in
> this, and see no reason to change from legacy encodings (or perhaps
> they have too much data to make that feasible).
> For this package, is it worth adding a note that it should be built
> from a UTF-8 environment, e.g. by passing LC_ALL=en_US.UTF-8 ?
> I note that in LFS we recommend a number of locales, not all UTF-8,
> for optimum test coverage (en_US.UTF-8 is one of these), followed by
> "In addition, install the locale for your own country, language and
> character set." so that if people decide to omit tests there is no
> guarantee about which locales will exist.
I have a problem with en_US.UTF-8. I generally do not have any LC_
variable set and even have
alias ls='LC_ALL=C ls --color=auto'
because I once was running into a problem with ls ignoring case when
If I do 'LC_ALL=en_US.UTF-8 man man', I get things like below.
without, it gives the expected
More information about the blfs-dev