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[3]: *** [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.
Dunno what would be best here.
ĸen
--
das eine Mal als Tragödie, dieses Mal als Farce
--
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
