On Thu 16 Oct 2014 02:30, Mark H Weaver 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
