GNU bug report logs - #15260
cannot build in a directory with non-ascii characters

Previous Next

Full log

View this message in rfc822 format

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Glenn Morris <rgm <at> gnu.org>, 15260 <at> debbugs.gnu.org, Kenichi Handa <handa <at> gnu.org>
Subject: bug#15260: cannot build in a directory with non-ascii characters
Date: Thu, 31 Oct 2013 15:24:57 -0400

> Below is what I came up with.  This survived several bootstraps, both

Thanks, Eli.

> +;; Make sure default-directory is unibyte when dumping.  This is
> +;; because we cannot decode and encode it correctly (since the locale
> +;; environment is not, and should not be, set up).  default-directory
> +;; is used every time we call expand-file-name, which we do in every
> +;; file primitive.  So the only workable solution to support building
> +;; in non-ASCII directories is to manipulate unibyte strings in the
> +;; current locale's encoding.
> +(if (and (or (equal (nth 3 command-line-args) "dump")
> +	     (equal (nth 4 command-line-args) "dump")
> +	     (equal (nth 3 command-line-args) "bootstrap")
> +	     (equal (nth 4 command-line-args) "bootstrap"))
> +	 (multibyte-string-p default-directory))
> +    (setq default-directory (string-to-unibyte default-directory)))

I'm not sure I understand this string-to-unibyte.
This call seems to only be correct if default-directory holds the
undecoded but multibyte name.
Why would we have an undecided yet multibyte name?

IOW, I'd expect here to either have default-directory be unibyte
already, or be multibyte but encoded in some (arbitrary) encoding (in
which case we can't really know how to re-encode it).


        Stefan

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.