On Thu 16 Oct 2014 02:30, Mark H Weaver <m...@netris.org> writes: > retitle 17399 Problems building guile-2.0.11 with libunistring 0.9.0 > thanks > > Hi Ed, > > I finally looked into this test failure that you experienced when > compiling guile-2.0.11 from source code on Ubuntu 12.04. I see that > you've since updated to Ubuntu 14.04, which includes guile-2.0.11, so > your problems are happily solved, but I'm still curious to learn what > happened here. > > To summarize, your problems all stemmed from a very old GNU libunistring > that you had installed in /usr/local. It was quite a bit older than the > minimum required version (0.9.3) which was packaged in Ubuntu 12.04. > The configure script identified the installed version as 0.9.0. > > You should probably remove that old version of libunistring, as it will > likely cause problems with other software you build from source. > > The rest of this email is primarily aimed at other Guile developers. > > * * * > > First, we should improve our configure script to bail out if the > libunistring is too old.
Done in master. That's enough to close this bug I think :) > After Ed had manually edited the old "unistr.h" to fix the compilation > problem, he encountered this test failure: > > ERROR: ports.test: unicode byte-order marks (BOMs): > Don't read from the port unless user asks to - arguments: > ((decoding-error "scm_from_stringn" "input locale conversion error" > 84 #vu8(254 255))) > > Here's the relevant section of test code in ports.test: > > (pass-if "Don't read from the port unless user asks to" > (let* ((p (make-soft-port > (vector > (lambda (c) #f) ; write char > (lambda (s) #f) ; write string > (lambda () #f) ; flush > (lambda () (throw 'fail)) ; read char > (lambda () #f)) > "rw"))) > (set-port-encoding! p "UTF-16") > (display "abc" p) > (set-port-encoding! p "UTF-32") > (display "def" p) > #t)) > > The error occurred within 'sf_write' in vports.c while writing the BOM > to the soft port (before writing "abc"). The problem is that soft ports > are fundamentally based on strings, and anything written to them is > first converted to a string (using the locale encoding) within > 'sf_write', in order to pass to the string to the user-provided "write" > procedure. Attempting to convert the UTF-16-encoded-BOM (0xFE 0xFF) to > the locale encoding failed, unsurprisingly. > > I believe the locale should have been "C", because of the call > (setlocale LC_ALL "C") in test-suite/guile-test. > > I'm actually surprised that this has ever worked, and it warrants > further investigation. It seems the BOM isn't being written. I don't know why. Let's open another bug if we find that there's a bug. Cheers, Andy