GNU bug report logs - #6401
Failure in loading charset map: JISX0208

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 6401 in the body.
You can then email your comments to 6401 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Sigve Berge Hofland <sigve <at> hofland.no>
To: bug-gnu-emacs <at> gnu.org
Subject: Failure in loading charset map: JISX0208
Date: Fri, 11 Jun 2010 12:53:41 +0100

Hi

My problem seems similar to bug#5249: 23.1.90 which has been closed,  
but I wasn't sure of the procedure of reopening, so I'm sending my  
report here. I hope that's all right.

When trying to 'make' 23.2 (from http://ftp.gnu.org/pub/gnu/emacs/ 
emacs-23.2.tar.gz) I get the following error (where '....' is '~/ 
Desktop/d'):

> Saving file ..../emacs-23.2/lisp/loaddefs.el...
> Failure in loading charset map: JISX0208
> make[2]: *** [autoloads] Error 255
> make[2]: Leaving directory `..../emacs-23.2/lisp'
> make[1]: *** [..../emacs-23.2/src/../lisp/loaddefs.el] Error 2
> make[1]: Leaving directory `..../emacs-23.2/src'
> make: *** [src] Error 2


I've tried './congfigure' with the options '--with-ns', '--with-ns -- 
with-x=no', and '--with-x'.

I've also tried the bzr version, and get a similar problem: ('....' =  
'/Users/sigve/Desktop/d/bzr-dir')

> Saving file ..../emacs/trunk/lisp/calendar/cal-loaddefs.el...
> Failure in loading charset map: JISX0208
> make[3]: *** [..../emacs/trunk/lisp/calendar/cal-loaddefs.el] Error  
> 255
> make[3]: Leaving directory `..../emacs/trunk/lisp'
> make[2]: *** [..../emacs/trunk/src/../lisp/loaddefs.el] Error 2
> make[2]: Leaving directory `..../emacs/trunk/src'
> make[1]: *** [src] Error 2
> make[1]: Leaving directory `..../emacs/trunk'
> make: *** [bootstrap] Error 2

The commands I used before this were:

> $ bzr init-repo emacs
> $ cd emacs
> $ bzr http://bzr.savannah.gnu.org/r/emacs/trunk/ trunk
> Branched 100577 revision(s).
> $ cd trunk
> $ ./configure --with-ns
> ...
> $  bzr pull
> Using saved parent location: http://bzr.savannah.gnu.org/r/emacs/ 
> trunk/
>  M  ChangeLog
>  M  Makefile.in
>  M  configure.in
>  M  etc/NEWS
> All changes applied successfully.
> Now on revision 100579.
> $ make bootstrap

In 'INSTALL.BZR' it says that with problems with 'loaddefs.el' one  
should try updating it, but then I get:

> ..../emacs/trunk/lisp sigve$ make autoloads
> EMACSLOADPATH=..../emacs/trunk/lisp LC_ALL=C ..../emacs/trunk/src/ 
> emacs -batch --no-site-file --multibyte -l autoload \
> 	   --eval "(setq generate-autoload-cookie \";;;###diary-autoload 
> \")" \
> 	   --eval "(setq generated-autoload-file \"..../emacs/trunk/lisp/ 
> calendar/diary-loaddefs.el\")" \
> 	   --eval "(setq make-backup-files nil)" \
> 	   -f batch-update-autoloads ..../emacs/trunk/lisp/calendar
> /bin/sh: line 1: ..../emacs/trunk/src/emacs: No such file or directory
> make: *** [..../emacs/trunk/lisp/calendar/diary-loaddefs.el] Error 127

I'm running Mac OS 10.4.11 on a G4 PPC processor (powerpc-apple- 
darwin8.11.0).

I hope that this report can be of some use, and apologize if it is not.

Best wishes
Sigve Berge Hofland

Message #8 received at 6401 <at> debbugs.gnu.org (full text, mbox):

From: Sigve Berge Hofland <sigve <at> hofland.no>
To: 6401 <at> debbugs.gnu.org
Date: Tue, 24 May 2011 17:30:58 +0100

[Message part 1 (text/plain, inline)]

The same error occurs in version 23.3:

> Saving file ..../emacs-23.3/lisp/loaddefs.el...
> Failure in loading charset map: JISX0208
> make[2]: *** [autoloads] Error 255
> make[1]: *** [..../emacs-23.3/src/../lisp/loaddefs.el] Error 2
> make: *** [src] Error 2

Attached are the outputs of configure and make.

[configure-output.txt (text/plain, attachment)]

[make-output.txt (text/plain, attachment)]

[Message part 4 (text/plain, inline)]

--
– Sigve

Message #11 received at 6401 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: Sigve Berge Hofland <sigve <at> hofland.no>
Cc: 6401 <at> debbugs.gnu.org
Subject: Re: bug#6401:
Date: Fri, 01 Jul 2011 21:01:31 -0400

Sigve Berge Hofland wrote:

> The same error occurs in version 23.3:
>
>> Saving file ..../emacs-23.3/lisp/loaddefs.el...
>> Failure in loading charset map: JISX0208
>> make[2]: *** [autoloads] Error 255
>> make[1]: *** [..../emacs-23.3/src/../lisp/loaddefs.el] Error 2

I'm sorry that you can't build Emacs.
I doubt the following is going to help, but:

It looks like you manage to build an emacs binary, but then fail
compiling some files.

1) Does the bootstrap-emacs start?

./src/bootstrap-emacs -Q 

2) If it starts, what is the value of `charset-map-path'?

Does the specified directory exist? Is it readable?
Does it contain JISX0208.map? Is it readable?


Failing that, you might try putting a breakpoint in
load_charset_map_from_file in charset.c to see if you can see why it
fails.

Message #12 received at 6401-quiet <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: 6401-quiet <at> debbugs.gnu.org
Subject: Re: bug#6401:
Date: Thu, 21 Jul 2011 15:09:54 -0400

Comment from bug#9132:

    > Failure in loading charset map: GB2312

    This comes from charset.c, FWIW, and the reason is a failed call to
    `fopen'.  It would be good to know the errno value for that failure,
    and also the value of Vcharset_map_path.

    Could it be that your system runs out of available file handles?  I
    didn't see such problems since the old DOS days, but what else can
    explain this?

Message #15 received at 6401 <at> debbugs.gnu.org (full text, mbox):

From: "Tim Daly Jr." <tim <at> tenkan.org>
To: 6401 <at> debbugs.gnu.org
Subject: Re: bug#6401: 
Date: Sun, 20 Nov 2011 18:33:50 -0800

I had the same problem.  Here's what seems to be going on:

charset.c is looking in Vdata_directory/charsets.

Vdata_directory gets set in callproc.c:

  char *data_dir = egetenv ("EMACSDATA");
...
  Vdata_directory
    = Ffile_name_as_directory (build_string (data_dir ? data_dir
					     : PATH_DATA));

I ran make from a shell buffer inside a carbon emacs process.  EMACSDATA, as well as several other such variables, are set:

$ env |grep ^EMACS
EMACSDATA=/Applications/Emacs.app/Contents/Resources/etc
EMACSPATH=/Applications/Emacs.app/Contents/MacOS/libexec:/Applications/Emacs.app/Contents/MacOS/bin
EMACS=t
EMACSLOADPATH=/Applications/Emacs.app/Contents/Resources/site-lisp:/Applications/Emacs.app/Contents/Resources/lisp:/Applications/Emacs.app/Contents/Resources/leim
EMACSDOC=/Applications/Emacs.app/Contents/Resources/etc

I unset EMACSDATA (and a few others, for the heck of it), and the build succeeded.

Cheers,
Tim

Message #18 received at 6401 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: "Tim Daly Jr." <tim <at> tenkan.org>
Cc: 6401 <at> debbugs.gnu.org
Subject: Re: bug#6401:
Date: Mon, 21 Nov 2011 18:31:18 -0500

"Tim Daly Jr." wrote:

> I ran make from a shell buffer inside a carbon emacs process.
> EMACSDATA, as well as several other such variables, are set:

Thanks for adding that comment, that would definitely explain it.

Although IIUC this particular issue would only occur if building Emacs
23+ from inside Emacs 22, and the OP did not mention that he was
doing that, so it might not be the same issue.

If it is this issue, I don't know what to do about it. It came up before
in the context of the MS Windows port:

http://lists.gnu.org/archive/html/emacs-devel/2008-10/msg00432.html

I don't know if a solution was ever found for that.

Message #21 received at 6401 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Glenn Morris <rgm <at> gnu.org>
Cc: 6401 <at> debbugs.gnu.org, tim <at> tenkan.org
Subject: Re: bug#6401:
Date: Tue, 22 Nov 2011 00:38:51 -0500

> From: Glenn Morris <rgm <at> gnu.org>
> Date: Mon, 21 Nov 2011 18:31:18 -0500
> Cc: 6401 <at> debbugs.gnu.org
> 
> If it is this issue, I don't know what to do about it. It came up before
> in the context of the MS Windows port:
> 
> http://lists.gnu.org/archive/html/emacs-devel/2008-10/msg00432.html
> 
> I don't know if a solution was ever found for that.

No solution was found, because I, like you, don't know what to do
about it.  Emacs has no way of knowing whether EMACSDATA etc. is set
for it or for some other Emacs.  So it cannot remove it from the
environment when running subprocesses.  Maybe someone could come up
with some clever idea.

Message #24 received at 6401 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 6401 <at> debbugs.gnu.org, tim <at> tenkan.org
Subject: Re: bug#6401:
Date: Tue, 22 Nov 2011 02:49:30 -0500

Eli Zaretskii wrote:

>> http://lists.gnu.org/archive/html/emacs-devel/2008-10/msg00432.html
>> 
>> I don't know if a solution was ever found for that.
>
> No solution was found, because I, like you, don't know what to do
> about it.  Emacs has no way of knowing whether EMACSDATA etc. is set
> for it or for some other Emacs.  So it cannot remove it from the
> environment when running subprocesses.  Maybe someone could come up
> with some clever idea.

If all else fails, we can at least write a PROBLEMS entry.
Why does a --with-ns build actually need to set these env-vars for child
processes?
Could they specifically be unset in spawned M-x shells?
Similar to the suggestion in emacs-devel, could configure unset
$EMACSDATA if $EMACS is set (which indicates it is running from an Emacs
shell)? Under what circusmtances would one want to set EMACSDATA when
building Emacs? Or could we replace the env-var with a --with-emacsdata
argument to configure instead? Then people who need the functionality
can still access it, and people who don't won't inadvertently get
affected by it.

Message #27 received at 6401 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Glenn Morris <rgm <at> gnu.org>
Cc: 6401 <at> debbugs.gnu.org, tim <at> tenkan.org
Subject: Re: bug#6401:
Date: Tue, 22 Nov 2011 03:36:53 -0500

> From: Glenn Morris <rgm <at> gnu.org>
> Cc: tim <at> tenkan.org,  6401 <at> debbugs.gnu.org
> Date: Tue, 22 Nov 2011 02:49:30 -0500
> 
> Why does a --with-ns build actually need to set these env-vars for child
> processes?
> Could they specifically be unset in spawned M-x shells?

How will Emacs know that these variables weren't set by the parent
shell?

> Similar to the suggestion in emacs-devel, could configure unset
> $EMACSDATA if $EMACS is set (which indicates it is running from an Emacs
> shell)? Under what circusmtances would one want to set EMACSDATA when
> building Emacs?

Building Emacs is just one use case, even if we find a solution for
it.  The problem is much broader: Emacs running as a child of another
Emacs gets EMACSDATA etc. variables that could well point to a wrong
place, because they were set by a different Emacs version.

Message #30 received at 6401 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 6401 <at> debbugs.gnu.org, tim <at> tenkan.org
Subject: Re: bug#6401:
Date: Tue, 22 Nov 2011 12:29:58 -0500

Eli Zaretskii wrote:

>> Why does a --with-ns build actually need to set these env-vars for child
>> processes?
>> Could they specifically be unset in spawned M-x shells?
>
> How will Emacs know that these variables weren't set by the parent
> shell?

I'm ignorant of all this. What do child processes of Emacs need these
variables for? Can you give me one example of something I might want to
run inside an emacs M-x shell buffer that needs to know EMACSDATA? It's
not set in shells spawned by a GNU/Linux build.

Also, don't you get a clear error about the charsets directory not being
found if EMACSDATA is wrong (from init_charset), rather than a failue to
load some particular charset? Which makes me think this is probably not
the problem the OP was having anyway...

Message #33 received at 6401 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 6401 <at> debbugs.gnu.org, tim <at> tenkan.org
Subject: Re: bug#6401:
Date: Tue, 22 Nov 2011 12:32:49 -0500

Eli Zaretskii wrote:

> Building Emacs is just one use case, even if we find a solution for
> it.  The problem is much broader: Emacs running as a child of another
> Emacs gets EMACSDATA etc. variables that could well point to a wrong
> place, because they were set by a different Emacs version.

But I would imagine that building Emacs from inside Emacs accounts for
the majority of cases where Emacs is run as a child of another Emacs.
(I can't think of any other reason one would want to do it.)

Message #36 received at 6401 <at> debbugs.gnu.org (full text, mbox):

From: "Tim Daly Jr." <tim <at> tenkan.org>
To: Glenn Morris <rgm <at> gnu.org>
Cc: 6401 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#6401:
Date: Tue, 22 Nov 2011 09:34:17 -0800

On Nov 22, 2011, at 9:29 AM, Glenn Morris wrote:
> 
> I'm ignorant of all this. What do child processes of Emacs need these
> variables for? Can you give me one example of something I might want to
> run inside an emacs M-x shell buffer that needs to know EMACSDATA? It's
> not set in shells spawned by a GNU/Linux build.
> 
> Also, don't you get a clear error about the charsets directory not being
> found if EMACSDATA is wrong (from init_charset), rather than a failue to
> load some particular charset? Which makes me think this is probably not
> the problem the OP was having anyway...

It's a warning:

      dir_warning ("Error: charsets directory (%s) does not exist.\n\
Emacs will not function correctly without the character map files.\n\
Please check your installation!\n",
                   tempdir);
      /* TODO should this be a fatal error?  (Bug#909)  */

what actually stopped my build was an error about loading that JIS charset.


-tim

Message #39 received at 6401 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 6401 <at> debbugs.gnu.org, tim <at> tenkan.org
Subject: Re: bug#6401:
Date: Tue, 22 Nov 2011 12:42:33 -0500

Glenn Morris wrote:

> What do child processes of Emacs need these variables for?

To be clear, I'm asking why ns_init_paths needs to do this kind of thing:

if (!getenv ("EMACSDATA"))
 setenv ("EMACSDATA", [resourcePath UTF8String], 1);

Message #42 received at 6401 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Glenn Morris <rgm <at> gnu.org>
Cc: 6401 <at> debbugs.gnu.org, tim <at> tenkan.org
Subject: Re: bug#6401:
Date: Tue, 22 Nov 2011 20:08:05 +0200

> From: Glenn Morris <rgm <at> gnu.org>
> Cc: tim <at> tenkan.org,  6401 <at> debbugs.gnu.org
> Date: Tue, 22 Nov 2011 12:29:58 -0500
> 
> Eli Zaretskii wrote:
> 
> >> Why does a --with-ns build actually need to set these env-vars for child
> >> processes?
> >> Could they specifically be unset in spawned M-x shells?
> >
> > How will Emacs know that these variables weren't set by the parent
> > shell?
> 
> I'm ignorant of all this. What do child processes of Emacs need these
> variables for? Can you give me one example of something I might want to
> run inside an emacs M-x shell buffer that needs to know EMACSDATA? It's
> not set in shells spawned by a GNU/Linux build.

Consider the case when the user sets this in the parent shell.  Then a
sub-shell will inherit it, and so will a sub-Emacs.

Don't know if this is the problems with ns, though.

Message #45 received at 6401 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Glenn Morris <rgm <at> gnu.org>
Cc: 6401 <at> debbugs.gnu.org, tim <at> tenkan.org
Subject: Re: bug#6401:
Date: Tue, 22 Nov 2011 20:09:54 +0200

> From: Glenn Morris <rgm <at> gnu.org>
> Cc: tim <at> tenkan.org,  6401 <at> debbugs.gnu.org
> Date: Tue, 22 Nov 2011 12:32:49 -0500
> 
> Eli Zaretskii wrote:
> 
> > Building Emacs is just one use case, even if we find a solution for
> > it.  The problem is much broader: Emacs running as a child of another
> > Emacs gets EMACSDATA etc. variables that could well point to a wrong
> > place, because they were set by a different Emacs version.
> 
> But I would imagine that building Emacs from inside Emacs accounts for
> the majority of cases where Emacs is run as a child of another Emacs.
> (I can't think of any other reason one would want to do it.)

The other important use case is running Emacs under a debugger invoked
through GUD.  This actually runs a higher risk of having two different
Emacs versions: imagine that a newer Emacs has a grave bug that
doesn't allow it to be used to run a debugger.

Message #48 received at 6401 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: 6401 <at> debbugs.gnu.org
Subject: Re: bug#6401:
Date: Tue, 22 Nov 2011 17:15:48 -0500

Glenn Morris wrote:

> To be clear, I'm asking why ns_init_paths needs to do this kind of thing:
>
> if (!getenv ("EMACSDATA"))
>  setenv ("EMACSDATA", [resourcePath UTF8String], 1);

IIUC, what's going on is:

The NS build can be made as some kind of relocatable "app bundle" where
paths to the doc file etc are not set during the build, but are figured
out at runtime. So there needs to be special NS-specific code to
initialize Vdata_directory etc. Rather than do this directly, the method
adopted is to call ns_init_paths early on in startup, to set environment
variables EMACSDATA etc. init_callproc_1 then uses these to initialize
Vdata_directory etc.

After this point, the environment variables hang around affecting all
sub-processes started by Emacs for no good reason.

I imagine the NS build could unset these environment variables, if it
set them itself, after initialization is complete. Or an NS-specific
init_callproc_1 would seem less clunky to me.

I also note that nsterm.m is still setting INFOPATH whereas w32.c has
stopped doing that.

The complete list is internal variables:

Vexec_path, Vdata_directory, Vdoc_directory, Vload_path, Info-directory-list

being set via env-vars:

EMACSPATH, EMACSDATA, EMACSDOC, EMACSLOADPATH, INFOPATH

Message #53 received at 6401-done <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: 6401-done <at> debbugs.gnu.org
Subject: Re: bug#6401: Failure in loading charset map: JISX0208
Date: Mon, 09 Jul 2012 21:06:34 -0400

Version: 24.2

In the emacs trunk, a missing charsets directory is now a fatal error;
also the ns port no longer sets any of the following environment
variables: EMACSPATH, EMACSDATA, EMACSDOC, EMACSLOADPATH, INFOPATH.
So this should be fixed.

Previous Next

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