bug#15260: cannot build in a directory with non-ascii characters

[Eli Zaretskii <eliz@gnu.org>]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Kenichi Handa <handa@gnu.org>,  15260@debbugs.gnu.org
> Date: Wed, 30 Oct 2013 21:01:21 -0400
> 
> > Why do we have this confusing inconsistency?
> 
> make_string is a bug.  There's no way to know/guess if the string should
> be unibyte or multibyte.  So, it should be removed and replaced by calls
> to either make_unibyte_string or make_multibyte_string.

Here's one more gotcha I bumped into while working on this bug.

Suppose the filesystem where you build Emacs uses a file-name encoding
whose coding-system-category is 'charset'.  Example: cpNNNN.  Then,
when Emacs comes up after dumping, it loads subdirs.el in each
directory on load-path.  To do this, it calls 'openp' to look for
DIR/subdirs.el, which involves calling ENCODE_FILE on
"DIR/subdirs.el", in order to pass that to 'faccessat' or 'open'.
Now, if the charset that is needed to encode this file name is not yet
loaded into Emacs, Emacs will try to load it.  To this end, it will
look along charset-map-path for the corresponding map file, and for
that it will again call 'openp', recursively.  That 'openp' call will
again want to ENCODE_FILE with the same encoding, which will again
cause Emacs to try to load the corresponding map file, etc. etc.,
until we exhaust the specpdl stack.

I worked around this by keeping charset-map-path in unibyte form until
later into the startup procedure.  Is there a more elegant and less
kludgey way?