bug-guile
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#17399: Fwd: Re: bug#17399: compilation bugs when making guile-2.0.11


From: Andy Wingo
Subject: bug#17399: Fwd: Re: bug#17399: compilation bugs when making guile-2.0.11
Date: Tue, 21 Jun 2016 15:45:46 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)

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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]