New dumping problem...

New dumping problem...

[David Kastrup]

On the newest Fedora Core tests, the setarch i386 workaround is no
longer sufficient for dumping.

It turns out that one way to fix this is to use

  echo 0 >/proc/sys/kernel/randomize_va_space

(which only root can do).

Uh oh.

The error message is

Dumping under names emacs and emacs-22.0.50
**************************************************
Warning: Your system has a gap between BSS and the
heap (6716260 byte).  This usually means that exec-shield
or something similar is in effect.  The dump may
fail because of this.  See the section about 
exec-shield in etc/PROBLEMS for more information.
**************************************************
make[1]: *** [bootstrap-emacs] Segmentation fault
make[1]: Leaving directory `/usr/local/tmp/emacs-build/src'
make: *** [bootstrap-build] Error 2

It seems like we are playing catchup with the operating system's
security games.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: New dumping problem...

[Jan D.]

David Kastrup wrote:

>On the newest Fedora Core tests, the setarch i386 workaround is no
>longer sufficient for dumping.
>
>It turns out that one way to fix this is to use
>
>  echo 0 >/proc/sys/kernel/randomize_va_space
>
>(which only root can do).
>
>Uh oh.
>  
>

Hmm, there is not much documentation of this, but what I can find is 
that this is a general feature in the Linux kernel from 2.6.11 or 
2.6.12-rc1, so other GNU/Linux distributions may also have it.  
Apparently it also breaks dosemu.

>The error message is
>
>Dumping under names emacs and emacs-22.0.50
>**************************************************
>Warning: Your system has a gap between BSS and the
>heap (6716260 byte).  This usually means that exec-shield
>or something similar is in effect.  The dump may
>fail because of this.  See the section about 
>exec-shield in etc/PROBLEMS for more information.
>**************************************************
>make[1]: *** [bootstrap-emacs] Segmentation fault
>make[1]: Leaving directory `/usr/local/tmp/emacs-build/src'
>make: *** [bootstrap-build] Error 2
>
>It seems like we are playing catchup with the operating system's
>security games.
>  
>

Indeed.  The final solution must be to either fix unexec (ELF I presume) 
or move away from unexec to something else.  I think the only thing we 
can do for now is to note this in etc/PROBLEMS.  It is too bad that root 
access is required on those systems to build Emacs.

    Jan D.

Re: New dumping problem...

[Thien-Thi Nguyen]

   From: "Jan D." <jan.h.d@swipnet.se>
   Date: Tue, 29 Mar 2005 21:41:59 +0200

   or move away from unexec to something else

under vms a "map file" is created (w/ the misleading name
"emacs.dump") and invocation is via a command procedure
(text script) that does "emacs.exe -map emacs.dump".
gory details at:

  http://www.glug.org/people/ttn/software/emacs-for-vms/

just fyi, something to keep in mind for the future.

thi

Re: New dumping problem...

[Richard Stallman]

    Indeed.  The final solution must be to either fix unexec (ELF I presume) 
    or move away from unexec to something else.

When you say "fix unexec", what does that mean?

Has anyone established that it is possible in principle
for unexec to do the right thing in this environment?
What change would be needed?

Does anyone understand what the technical issue is?

Re: New dumping problem...

[Jan D.]

>     Indeed.  The final solution must be to either fix unexec (ELF I 
> presume)
>     or move away from unexec to something else.
>
> When you say "fix unexec", what does that mean?
>
> Has anyone established that it is possible in principle
> for unexec to do the right thing in this environment?
> What change would be needed?
>
> Does anyone understand what the technical issue is?

I haven't checked this specific problem, but the exec-shield problem 
was that there is a hole between data and bss.  unexelf.c assumes these 
are next to each other.  It should be possible to make two data 
sections, one for the original data and one for the original bss, that 
are mapped to two different addresses when dumping.  But then sections 
in the dumped image needs to be expanded and that is tricky as all 
sections after needs to be moved as well.

	Jan D.

Re: New dumping problem...

[Richard Stallman]

      It should be possible to make two data 
    sections, one for the original data and one for the original bss, that 
    are mapped to two different addresses when dumping.  But then sections 
    in the dumped image needs to be expanded and that is tricky as all 
    sections after needs to be moved as well.

It does look tricky, but in principle it shouldn't be hard.  So I
conclude that this really is a bug in Emacs, and the right place to
fix it is in Emacs.

I think we have to fix this before the coming release.  Can someone
please volunteer to do it?

Re: New dumping problem...

[Nick Roberts]

Richard Stallman writes:
 >       It should be possible to make two data 
 >     sections, one for the original data and one for the original bss, that 
 >     are mapped to two different addresses when dumping.  But then sections 
 >     in the dumped image needs to be expanded and that is tricky as all 
 >     sections after needs to be moved as well.
 > 
 > It does look tricky, but in principle it shouldn't be hard.  So I
 > conclude that this really is a bug in Emacs, and the right place to
 > fix it is in Emacs.
 > 
 > I think we have to fix this before the coming release.  Can someone
 > please volunteer to do it?

Jim Phelps? Or has he retired now?

Nick

Re: New dumping problem...

[Richard Stallman]

    Jim Phelps? Or has he retired now?

Sorry, I don't recognize the name.

Re: New dumping problem...

[Richard Stallman]

    It turns out that one way to fix this is to use

      echo 0 >/proc/sys/kernel/randomize_va_space

    (which only root can do).

At this point I think we decide it's their problem, not our problem,
and send them a bug report.

Re: New dumping problem...

[Katsumi Yamaoka]

Hi,

I'm trying to build Emacs CVS on the Fedora Core 4-release, but
haven't been successful yet.  Have anyone achieved it?  The
workarounds described in etc/PROBLEMS weren't effective and the
following wasn't either.

>>>>> In <x5is3bpbjf.fsf@lola.goethe.zz> 
>>>>>	David Kastrup <dak@gnu.org> wrote:

> On the newest Fedora Core tests, the setarch i386 workaround is no
> longer sufficient for dumping.

> It turns out that one way to fix this is to use

>   echo 0 >/proc/sys/kernel/randomize_va_space

> (which only root can do).

> Uh oh.

echo 0 >/proc/sys/kernel/randomize_va_space
cat /proc/sys/kernel/randomize_va_space
1

Re: New dumping problem...

[Masatake YAMATO]

Hi, Yamaoka-san

> I'm trying to build Emacs CVS on the Fedora Core 4-release, but
> haven't been successful yet.  Have anyone achieved it?  The
> workarounds described in etc/PROBLEMS weren't effective and the
> following wasn't either.

It seems that I'll work on this issue in this weekend:)
I installed FC4 yesterday. And now I can reproduce the problem.

Re: New dumping problem...

[Masatake YAMATO]

> Hi,
> 
> I'm trying to build Emacs CVS on the Fedora Core 4-release, but
> haven't been successful yet.  Have anyone achieved it?  The
> workarounds described in etc/PROBLEMS weren't effective and the
> following wasn't either.

When running make, could you try -R option with setarch?

$ setarch i386 -R make


Regards,
Masatake YAMATO

Re: New dumping problem...

[Katsumi Yamaoka]

>>>>> <20050618.020729.192953061.jet@gyve.org> YAMATO-san wrote:

>> I'm trying to build Emacs CVS on the Fedora Core 4-release, but
>> haven't been successful yet.

> When running make, could you try -R option with setarch?

> $ setarch i386 -R make

Thank you very much for looking into it.  I'm now home where
there's not the pc in which Fedore Core 4 is installed, but I'll
try that measure in Monday.  Did you succeed with it?

Re: New dumping problem...

[Masatake YAMATO]

> >>>>> <20050618.020729.192953061.jet@gyve.org> YAMATO-san wrote:
> 
> >> I'm trying to build Emacs CVS on the Fedora Core 4-release, but
> >> haven't been successful yet.
> 
> > When running make, could you try -R option with setarch?
> 
> > $ setarch i386 -R make
> 
> Thank you very much for looking into it.  I'm now home where
> there's not the pc in which Fedore Core 4 is installed, but I'll
> try that measure in Monday.  Did you succeed with it?

Yes, I did.

Re: New dumping problem...

[Katsumi Yamaoka]

>>>>> In <20050618.122801.78242809.jet@gyve.org>
>>>>>	Masatake YAMATO <jet@gyve.org> wrote:

>>> When running make, could you try -R option with setarch?

>>> $ setarch i386 -R make

>> Thank you very much for looking into it.  I'm now home where
>> there's not the pc in which Fedore Core 4 is installed, but I'll
>> try that measure in Monday.  Did you succeed with it?

> Yes, I did.

I succeeded in building Emacs under Fedora Core 4 with:

./configure args... ; setarch i386 -R make bootstrap

Thanks again.

Even if I used the `-R' option, I also confirmed wrapping temacs
with `setarch i386 -R' when dumping Emacs (as described in
etc/PROBLEMS) was ineffective.

BTW, FC4 eats the C-SPC key for the `iiimx' program which is the
input method for (at least?) Japanese text by default, so I
couldn't use C-SPC for `set-mark-command' in Emacs.  Liang Zhao
kindly told me that it can be solved by removing `<Ctrl>space'
from the /usr/lib/X11/app-defaults/Iiimx file, and I put it into
practice.  Furthermore, I saw I can simply remove that file.
While I did so, I'm still able to start writing Japanese text in
gnome-terminal, Firefox, etc. using C-SPC or S-SPC.  Although I
cannot use C-SPC in Emacs started with the `-nw' option in
gnome-terminal, it will probably be solved by modifying the X
resources for gnome-terminal (I haven't found the way for that
yet, though).

Regards,

Re: New dumping problem...

[Masatake YAMATO]

> I succeeded in building Emacs under Fedora Core 4 with:
> 
> ./configure args... ; setarch i386 -R make bootstrap
> 
> Thanks again.
> 
> Even if I used the `-R' option, I also confirmed wrapping temacs
> with `setarch i386 -R' when dumping Emacs (as described in
> etc/PROBLEMS) was ineffective.

Thank you for reporting.

All, is it enough as a temporally solution?

What should I do next?
Should I write it in etc/PROBLEMS?
Or should I modify Makefile.in and configure.in to wrap temacs with
`setarch i386 -R'?

Masatake

Re: New dumping problem...

[Richard Stallman]

    I succeeded in building Emacs under Fedora Core 4 with:

    ./configure args... ; setarch i386 -R make bootstrap

1. Can people determine if this is a full solution?

2. If it is, can we reprogram configure.in
and the makefiles to do this automatically when it's called for?

Re: New dumping problem...

[Masatake YAMATO]

> 
>     I succeeded in building Emacs under Fedora Core 4 with:
> 
>     ./configure args... ; setarch i386 -R make bootstrap
> 
> 1. Can people determine if this is a full solution?
> 
> 2. If it is, can we reprogram configure.in
> and the makefiles to do this automatically when it's called for?

It seems that only two Japanese-guys use Emacs on FC4:-)

Index: etc/PROBLEMS
===================================================================
RCS file: /cvsroot/emacs/emacs/etc/PROBLEMS,v
retrieving revision 1.176
diff -u -r1.176 PROBLEMS
--- etc/PROBLEMS	25 Jun 2005 04:48:24 -0000	1.176
+++ etc/PROBLEMS	26 Jun 2005 14:48:40 -0000
@@ -2377,7 +2377,9 @@
 
 With certain recent Linux kernels (like the one of Redhat Fedora Core
 1 and 2), the new "Exec-shield" functionality is enabled by default, which
-creates a different memory layout that breaks the emacs dumper.
+creates a different memory layout that breaks the emacs dumper. 
+The work-around explained here is not enough on Fedora Core 4. Read the
+next item.
 
 Configure can overcome the problem of exec-shield if the architecture is
 x86 and the program setarch is present.  On other architectures no
@@ -2404,6 +2406,20 @@
 
     setarch i386 ./temacs --batch --load loadup [dump|bootstrap]
 
+*** Fedora Core 4 GNU/Linux: Segfault during dumping.
+
+In addition to exec-shield explained above "Linux: Segfault during
+`make bootstrap' under certain recent versions of the Linux kernel"
+item, Linux kernel shipped with Fedora Core 4 randomizes the virtual
+address space of a process. As the result dumping is failed even if
+you turn off the exec-shield. In such case use -R option of setarch
+command:
+
+   setarch -R i386 ./temacs --batch --load loadup [dump|bootstrap]
+
+or
+
+   setarch -R i386 make bootstrap	
 
 *** Fatal signal in the command  temacs -l loadup inc dump.

Re: New dumping problem...

[Jason Rumney]

Masatake YAMATO <jet@gyve.org> writes:

> +The work-around explained here is not enough on Fedora Core 4. Read the
> +next item.
>  
....
>      setarch i386 ./temacs --batch --load loadup [dump|bootstrap]
>  
> +*** Fedora Core 4 GNU/Linux: Segfault during dumping.
> +
> +In addition to exec-shield explained above "Linux: Segfault during
> +`make bootstrap' under certain recent versions of the Linux kernel"
> +item, Linux kernel shipped with Fedora Core 4 randomizes the virtual
> +address space of a process. As the result dumping is failed even if
> +you turn off the exec-shield. In such case use -R option of setarch
> +command:
> +
> +   setarch -R i386 ./temacs --batch --load loadup [dump|bootstrap]
> +
> +or
> +
> +   setarch -R i386 make bootstrap	

If "setarch -R i386 make bootstrap" would work on all problem kernels,
why don't we simplify these two entries, and just recommend that for
both cases?

Re: New dumping problem...

[Masatake YAMATO]

> > +The work-around explained here is not enough on Fedora Core 4. Read the
> > +next item.
> >  
> ....
> >      setarch i386 ./temacs --batch --load loadup [dump|bootstrap]
> >  
> > +*** Fedora Core 4 GNU/Linux: Segfault during dumping.
> > +
> > +In addition to exec-shield explained above "Linux: Segfault during
> > +`make bootstrap' under certain recent versions of the Linux kernel"
> > +item, Linux kernel shipped with Fedora Core 4 randomizes the virtual
> > +address space of a process. As the result dumping is failed even if
> > +you turn off the exec-shield. In such case use -R option of setarch
> > +command:
> > +
> > +   setarch -R i386 ./temacs --batch --load loadup [dump|bootstrap]
> > +
> > +or
> > +
> > +   setarch -R i386 make bootstrap	
> 
> If "setarch -R i386 make bootstrap" would work on all problem kernels,
> why don't we simplify these two entries, and just recommend that for
> both cases?

-R option may be introduced in FC4.

Re: New dumping problem...

[Richard M. Stallman]

Thanks for writing an item for PROBLEMS.  I will install it.

But I would still like to ask,
Can we reprogram configure.in and the makefiles to do this
automatically when it's called for?

Re: New dumping problem...

[Masatake YAMATO]

> Thanks for writing an item for PROBLEMS.  I will install it.

Please, do so.

> But I would still like to ask,
> Can we reprogram configure.in and the makefiles to do this
> automatically when it's called for?
> 

I will do it in next Sunday. However, I wonder the -R option is
enough for FC4 running on powerpc or not. 

Re: New dumping problem...

[Masatake YAMATO]

> Thanks for writing an item for PROBLEMS.  I will install it.
> 
> But I would still like to ask,
> Can we reprogram configure.in and the makefiles to do this
> automatically when it's called for?

I find the way to fix the problem in C source code level.
I have already installed the fix.
Please, try to run make without setarch.

Masatake YAMATO

Re: New dumping problem...

[Katsumi Yamaoka]

>>>>> In <20050701.012657.123274320.yamato@redhat.com> Masatake YAMATO wrote:

> I find the way to fix the problem in C source code level.
> I have already installed the fix.
> Please, try to run make without setarch.

Great!  I succeeded in building the latest Emacs with FC4 and
Solaris machines by using the same procedure as:

./configure --without-xim; make bootstrap

Thank you so much.

Re: New dumping problem...

[Richard M. Stallman]

    I find the way to fix the problem in C source code level.
    I have already installed the fix.
    Please, try to run make without setarch.

Thank you.

Can you eliminate this exec_shield problem too?

*** Linux: Segfault during `make bootstrap' under certain recent versions of the Linux kernel.

Re: New dumping problem...

[jhd]

>
> I find the way to fix the problem in C source code level.
> I have already installed the fix.
> Please, try to run make without setarch.

Is there no #define in some header-file you can look for?  A  
configure test would be preferrable to hardcoding OS specific  
constants into Emacs.

           /* A flag to turn off address randomization which is  
introduced
            in linux kernel shipped with fedora core 4 */
#define ADD_NO_RANDOMIZE 0x0040000
           personality (PER_LINUX32 | ADD_NO_RANDOMIZE);
#undef  ADD_NO_RANDOMIZE


FWIW, Fedora core 2 works OK with this change.

     Jan D.

Re: New dumping problem...

[Masatake YAMATO]

> >
> > I find the way to fix the problem in C source code level.
> > I have already installed the fix.
> > Please, try to run make without setarch.
> 
> Is there no #define in some header-file you can look for?

Good question. The answer is no.

> A configure test would be preferrable to hardcoding OS specific
> constants into Emacs.

The test may pass any linux kernel which has personality system call.
I guess there is no way to test.

> FWIW, Fedora core 2 works OK with this change.

Thank you. I've tested on FC1, and FC4.
Your personality hack, the replacement of setarch invocation also
helps me.

Masatake YAMATO

Re: New dumping problem...

[Richard M. Stallman]

    The test may pass any linux kernel which has personality system call.
    I guess there is no way to test.

It is easy to test whether that system call exists.
That is what Autoconf is good at.

If that is all we need to test, let's do it.

Re: New dumping problem...

[Masatake YAMATO]

>     The test may pass any linux kernel which has personality system call.
>     I guess there is no way to test.
> 
> It is easy to test whether that system call exists.
> That is what Autoconf is good at.
> 
> If that is all we need to test, let's do it.

No. The test whether that system call exists was already done by Jan D.
I have just added a flag to a parameter which is passed to the personality
system call for Fedora Core 4. Linux kernel shipped with FC[1-3] just ignores
the flag. The flag affects a kernel shipped with FC4. As the result it is not
so meaningful to test whether the flag is effective or not with autoconf; the
test will never be failed on any environment where the personality system call
is available.

Masatake YAMATO

Re: New dumping problem...

[Richard M. Stallman]

    The flag affects a kernel shipped with FC4. As the result it is not
    so meaningful to test whether the flag is effective or not with autoconf; the
    test will never be failed on any environment where the personality system call
    is available.

So it sounds like the current code actually has no problem, then.
That's ok.

Re: New dumping problem...

[Richard M. Stallman]

    FWIW, Fedora core 2 works OK with this change.

Does that mean we can delete the other PROBLEMS item?
(The one about exec_shield, that is.)

Re: New dumping problem...

[jhd]

>     FWIW, Fedora core 2 works OK with this change.
>
> Does that mean we can delete the other PROBLEMS item?
> (The one about exec_shield, that is.)

The exec-shield workaround kicks in if the difference between the end  
of the data section and the start of the heap is greater than  
MAX_HEAP_BSS_DIFF which is 1 Mbyte.  But MAX_HEAP_BSS_DIFF is a value  
I came up with when examining the exec-shield code in the Linux  
kernel for Fedora 2.  However, there is nothing preventing a new exec- 
shield implementation to change this.  Also, as far as I know, the  
workaround has only been tested on the ix86 architecture.

So I'd propose we keep it in PROBLEMS, but we could add that Emacs  
tries to handle exec-shield itself.  A note on how to disable the  
randomization should be added to PROBLEMS also.

     Jan D.

Re: New dumping problem...

[Richard M. Stallman]

    So I'd propose we keep it in PROBLEMS, but we could add that Emacs  
    tries to handle exec-shield itself.  A note on how to disable the  
    randomization should be added to PROBLEMS also.

Could you please do that?

Re: New dumping problem...

[Jan D.]

>     So I'd propose we keep it in PROBLEMS, but we could add that Emacs
>     tries to handle exec-shield itself.  A note on how to disable the
>     randomization should be added to PROBLEMS also.
>
> Could you please do that?
>

I reinstated the text you added about Fedora Core 4, and added that  
Emacs tries to handle this at build time.

     Jan D.

Re: New dumping problem...

[Richard Stallman]

    BTW, FC4 eats the C-SPC key for the `iiimx' program which is the
    input method for (at least?) Japanese text by default, so I
    couldn't use C-SPC for `set-mark-command' in Emacs.  Liang Zhao
    kindly told me that it can be solved by removing `<Ctrl>space'
    from the /usr/lib/X11/app-defaults/Iiimx file, and I put it into
    practice.

That requires you to be root.  Is there something an unprivileged
user can do, to achieve the same result?

Re: New dumping problem...

[Katsumi Yamaoka]

>>>>> In <E1DkQQo-0007ZY-Sa@fencepost.gnu.org> Richard Stallman wrote:

>     BTW, FC4 eats the C-SPC key for the `iiimx' program which is the
>     input method for (at least?) Japanese text by default, so I
>     couldn't use C-SPC for `set-mark-command' in Emacs.  Liang Zhao
>     kindly told me that it can be solved by removing `<Ctrl>space'
>     from the /usr/lib/X11/app-defaults/Iiimx file, and I put it into
>     practice.

> That requires you to be root.  Is there something an unprivileged
> user can do, to achieve the same result?

Now I cannot reproduce the problem that FC4 eats the C-SPC key
even though I put the Iiimx file back into the default.  FC4
seems to remember the configuration which doesn't bind the C-SPC
key somewhere, but I couldn't find it so far (neither loading of
the resource file by xrdb nor rebooting of the system is
effective).  I guess it can be solved by adding the following
one to the ~/.Xdefaults file though I cannot confirm it.  Sorry.

Iiimx*conversionOnKeys: <Shift>space

The contents of the original Iiimx file are as follows:

!! conversion key
*conversionOnKeys: <Ctrl>space <Shift>space

Re: New dumping problem...

[Katsumi Yamaoka]

There's no way for unprivileged users to avoid the problem that
the Fedora Core 4 eats the C-SPC key.

>>>>> In <b9y7jgn881d.fsf@jpl.org> Katsumi Yamaoka wrote:

>>     BTW, FC4 eats the C-SPC key for the `iiimx' program which is the
>>     input method for (at least?) Japanese text by default, so I
>>     couldn't use C-SPC for `set-mark-command' in Emacs.  Liang Zhao
>>     kindly told me that it can be solved by removing `<Ctrl>space'
>>     from the /usr/lib/X11/app-defaults/Iiimx file, and I put it into
>>     practice.

>> That requires you to be root.  Is there something an unprivileged
>> user can do, to achieve the same result?

> Now I cannot reproduce the problem that FC4 eats the C-SPC key
> even though I put the Iiimx file back into the default.

While I always use the GNOME desktop, I could reproduce the
problem by using the KDE desktop.  Modifying the Iiimx resource
file is effective there, but only that file is read when the
user logged in.  It is ineffective to load the Iiimx file or the
~/.Xdefaults file by xrdb as well as the GNOME desktop.
Furthermore, the `iiimf-le-tools'[1] command  doesn't work at
both the desktops.

[1] http://www.fedora.redhat.com/projects/i18n/iiimf-faq.html

By the way, Emacs built with the `--without-xim' option has no
problem for fetching the C-SPC key.  I built Emacs 21.4 and
22.0.50 and confirmed it.  I think that it can become the
default since Emacs provides the input methods of practical use.

Re: New dumping problem...

[Richard M. Stallman]

    There's no way for unprivileged users to avoid the problem that
    the Fedora Core 4 eats the C-SPC key.

    By the way, Emacs built with the `--without-xim' option has no
    problem for fetching the C-SPC key.

Those two statements seem to contradict each other, so I do not
understand.  Which of these two is the case?

* Nonprivileged Emacs users can avoid the C-SPC problem by building
  Emacs with `--without-xim'.

* Nonprivileged Emacs users cannot avoid the C-SPC problem.

Re: New dumping problem...

[Katsumi Yamaoka]

>>>>> In <E1DlFz4-000836-2D@fencepost.gnu.org> Richard M. Stallman wrote:

>     There's no way for unprivileged users to avoid the problem that
>     the Fedora Core 4 eats the C-SPC key.

>     By the way, Emacs built with the `--without-xim' option has no
>     problem for fetching the C-SPC key.

> Those two statements seem to contradict each other, so I do not
> understand.  Which of these two is the case?

I'm sorry to confuse you.  This one is right:

> * Nonprivileged Emacs users can avoid the C-SPC problem by building
>   Emacs with `--without-xim'.

She or he will be able to run Emacs built in the home directory.

Re: New dumping problem...

[Kim F. Storm]

Katsumi Yamaoka <yamaoka@jpl.org> writes:

>> * Nonprivileged Emacs users can avoid the C-SPC problem by building
>>   Emacs with `--without-xim'.
>
> She or he will be able to run Emacs built in the home directory.

.. or maybe just set the X resource useXIM to false.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: New dumping problem...

[Katsumi Yamaoka]

>>>>> In <m38y11ikb8.fsf@kfs-l.imdomain.dk> Kim F. Storm wrote:

> Katsumi Yamaoka <yamaoka@jpl.org> writes:

>>> * Nonprivileged Emacs users can avoid the C-SPC problem by building
>>>   Emacs with `--without-xim'.
>>
>> She or he will be able to run Emacs built in the home directory.

> .. or maybe just set the X resource useXIM to false.

Unfortunately, it didn't the trick.  I put the following lines
in the ~/.Xdefaults file, read it using xrdb and started
/usr/bin/emacs (which comes from the Fedora Core 4).

*useXim: false
Emacs*useXim: false
emacs*useXim: false

Re: New dumping problem...

[Kim F. Storm]

Katsumi Yamaoka <yamaoka@jpl.org> writes:

> *useXim: false
> Emacs*useXim: false
> emacs*useXim: false

Could you try useXIM

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: New dumping problem...

[Katsumi Yamaoka]

>>>>> In <m3ll51gnb9.fsf@kfs-l.imdomain.dk> Kim F. Storm wrote:

> Katsumi Yamaoka <yamaoka@jpl.org> writes:

>> *useXim: false
>> Emacs*useXim: false
>> emacs*useXim: false

> Could you try useXIM

Oops, I mistook the case.  I retried it in the KDE desktop (as I
wrote in <b9y7jgn881d.fsf@jpl.org>, the problem has disappeared
in the GNOME desktop for the unknown reason).

The ``Emacs*useXII: false'' line is effective for the Emacs
which I built with the ``--with-xim'' option.  However, to be
effective in /usr/bin/emacs-21.4-x is only to modify the Iiimx
resource file after all.  I don't know how Fedore made it, but
seem it was made so as to be used together with Iiimx rigidly.

Re: New dumping problem...

[Katsumi Yamaoka]

>>>>> In <b9y8y10lhav.fsf@jpl.org> Katsumi Yamaoka wrote:

> The ``Emacs*useXII: false'' line is...

That's a typo of ``Emacs*useXIM: false''.  Sorry.

Re: New dumping problem...

[Stefan Monnier]

> The ``Emacs*useXIM: false'' line is effective for the Emacs
> which I built with the ``--with-xim'' option.  However, to be
> effective in /usr/bin/emacs-21.4-x is only to modify the Iiimx

IIRC, the useXIM resource is new in Emacs-CVS so it's no wonder it doesn't
work in Emacs-21.4.


        Stefan

Re: New dumping problem...

[Richard M. Stallman]

    The ``Emacs*useXII: false'' line is effective for the Emacs
    which I built with the ``--with-xim'' option.

Can we make Emacs to simply do this, on its own, without requiring the
user to specify anything in his X resources?

I am sure a program can override the X resource setting.
The only questions are (1) does someone know precisely what
it needs to do, and (2) would there be any downside,
perhaps on other systems, to doing this?

Re: New dumping problem...

[Richard M. Stallman]

    > * Nonprivileged Emacs users can avoid the C-SPC problem by building
    >   Emacs with `--without-xim'.

    She or he will be able to run Emacs built in the home directory.

That is good news.  Could someone write an item for etc/PROBLEMS?

Re: New dumping problem...

[Katsumi Yamaoka]

>>>>> In <E1Dlgr1-0001RH-9Y@fencepost.gnu.org> Richard M. Stallman wrote:

>> * Nonprivileged Emacs users can avoid the C-SPC problem by building
>>   Emacs with `--without-xim'.

>     She or he will be able to run Emacs built in the home directory.

> That is good news.  Could someone write an item for etc/PROBLEMS?

I wrote it, but it will probably be necessary to be corrected by
someone since I'm not a native writer. ;-)

It was reported that there is a problem that the Redhat Fedora Core 4
steals the C-SPC key by default for the `iiimx' program which is the
input method for some languages.  It blocks Emacs users from using the
C-SPC key for `set-mark-command'.  Currently, two ways to solve it are
known.  One is to remove the `<Ctrl>space' from the Iiimx file which
can be found in the /usr/lib/X11/app-defaults directory.  The other is
to rebuild Emacs using the `--without-xim' configure option.

Re: New dumping problem...

[Richard M. Stallman]

I polished the wording and installed it in PROBLEMS.

However, it would still be nice to make Emacs DTRT automatically.

Re: New dumping problem...

[Richard Stallman]

    I'm trying to build Emacs CVS on the Fedora Core 4-release, but
    haven't been successful yet.  Have anyone achieved it?  The
    workarounds described in etc/PROBLEMS weren't effective and the
    following wasn't either.

The point is, we need to update unexec so it can handle this right.