Re: emacs-19.34 segfauls when built with Xfree 4.3.0 (glibc 2.3.x,gcc 3.2)

Re: emacs-19.34 segfauls when built with Xfree 4.3.0 (glibc 2.3.x,gcc 3.2)

[Hin-Tak Leung]

That's a somewhat time-wasting question - if I am on linux with
gcc 3.2 glibc 2.3.x and Xfree 4.3.0 most certainly the linux
distribution I use come with a more recent version of emacs or xemacs.
(actually both). And my original post mentioned that I built emacs-19
successfully on a Xfree 4.1/glibc 2.0/2.1 system as well,
and that binary still works on the current system.

I want to use a elisp script called cemacs (for Chinese inputs)
but unfortunately the inclusion the MULE (Multi-lingual Extension)
since version 20 has broken it. It does continue to work with
xemacs-21.x, but that's besides the point.

Now back to my question: why emacs 19.34 segfault when built against
glibc-2.3 and Xfree 4.3.0? And please stick to the question... -
and please do not ask why I don't switch to xemacs, or use MULE.

Just to anticipate these two questions: MULE is no where as good
as cemacs (unfortunately, and please don't start an argument on why I
should use MULE even though it is inferior), and xemacs is too
bloated for my taste. So I would really rather try to keep using
a small installation of 19.34 (in addition to emacs 21 which came
with the distro), or port cemacs forward to emacs 21 (quite major
work, probably). The 2nd option is probably better for long
term, but until it is done, I will continue to try to build emacs
19 on current systems... and I would really like to find out
why it won't build.

==============
Hin-Tak Leung wrote:
> I am trying to build emacs-19.34 against glibc-2.3 and Xfree 4.3.0
> on linux with gcc 3.2. The binary works with -nw switch, but
> when I run it without -nw, it segfaults with Fatal Error(11).
> So it seems to be an X-related problem.

have you tried using a more recent version of emacs? emacs-21.3.1 is
what i use and it compiled with gcc-3.2.3 on XFree86-4.3 no problems
(glibc-3.2.3) using using Lesstif-0.93.41. unless there is some reason
you WANT to use an older version?

cheers,
Sam

Re: emacs-19.34 segfauls when built with Xfree 4.3.0 (glibc 2.3.x,gcc 3.2)

[Thien-Thi Nguyen]

Hin-Tak Leung <hintak_leung@yahoo.co.uk> writes:

   Now back to my question: why emacs 19.34 segfault when built against
   glibc-2.3 and Xfree 4.3.0? And please stick to the question... - and
   please do not ask why I don't switch to xemacs, or use MULE.

in this case probably no one can answer your question w/o your investing
effort into debugging the matter locally.  as well, probably few people
are interested in helping you if you scold them.

of course, there is the option of hiring someone to work on this problem
for you, in which case you can treat them as befits the conventional (in
your business sphere) employer / employee relationship, and clearly set
out in a written contract.  you may consult the etc/SERVICES file to
find someone in your vicinity, or further away on the net.

thi

Re: emacs-19.34 segfaults when built with Xfree 4.3.0 (glibc2.3.x,gcc 3.2)

[Hin-Tak Leung]

This is going more and more off-topic. My initial post was fairly
specific, and the one reply I got (asking why I don't use a more
current version) was already somewhat off-topic, because I did
describe my system in much detail and it would have been obvious even
at that point I had a (not yet disclosed) reason not to use a
more current version.

But unless of course, you would rather me switching to xemacs-21 instead...

(cemacs still continue to work under it, as the emacs/xemacs split
occurred before version 19, and the xemacs folks are less agressive
in making incompatible changes - which unfortunately is also the
reason of xemacs's bloatedness; however I believe MULE is going into
xemacs-24 or thereabout's so the issue will need to be addressed one day,
even if I switch to xemacs).

FWIW, I did search through the archive for "Fatal Error(11)".
And it seems to be the message for a general memory access error,
similar to the gcc's SIG 11 (probably identical to...), or
the rather uninformative "segmentation fault" whenever any program dies;
and fatal error 11 can occur under a lot of totally unrelated conditions,
but mostly to do with how undump works, memory aligment, etc.

So my guess is that it is probably going to be very sensitive
to how my glibc, Xfree86, or my gcc were configured and built and
any patches were applied to them; and there *might* be a chance
that a future system upgrade *might* magically fixes it.

In any case, the reality is that I only need emacs-19 to work in
the "-nw" enviroment for cemacs, and figuring out why it
segfaults under Xfree86 is a somewhat academic issue... but
I would still like an answer, an explanation, or (gasp) a
possible fix.

OTOH, if I really want a "currently supported" emacs for my purpose,
I could switch to xemacs-21 immediately and that would give me
a couple of years to look for other alternatives...

Thien-Thi Nguyen wrote:
> Hin-Tak Leung <hintak_leung@yahoo.co.uk> writes:
> 
>    Now back to my question: why emacs 19.34 segfault when built against
>    glibc-2.3 and Xfree 4.3.0? And please stick to the question... - and
>    please do not ask why I don't switch to xemacs, or use MULE.
> 
> in this case probably no one can answer your question w/o your investing
> effort into debugging the matter locally.  as well, probably few people
> are interested in helping you if you scold them.
> 
> of course, there is the option of hiring someone to work on this problem
> for you, in which case you can treat them as befits the conventional (in
> your business sphere) employer / employee relationship, and clearly set
> out in a written contract.  you may consult the etc/SERVICES file to
> find someone in your vicinity, or further away on the net.
> 
> thi
> 

Re: emacs-19.34 segfauls when built with Xfree 4.3.0 (glibc 2.3.x,gcc 3.2)

[Hin-Tak Leung]

That's another pointless reply... you still have not offered
any substantial help - e.g. suggestion for compiler switches,
small modification at the source level, etc.

FWIW, I had tried both "-D_BSD_SOURCE" (the default)
and also "-D_GNU_SOURCE -D_BSD_SOURCE" (how the redhat
4.x rpm was built). Both binaries work happily with "-nw" inside
an xterm and seg-fault under X.

Thanks for another "I am trying to help and I am not saying anything" post...

Sam Halliday wrote:
> Hin-Tak Leung wrote:
> 
>>>>I am trying to build emacs-19.34
> 
> <snip>
> 
>>>have you tried using a more recent version of emacs?
> 
> <snip>
> 
>>That's a somewhat time-wasting question
> 
> 
> don't be a cheeky fucker! i was being nice to you and trying to help,
> now don't reply off list... and please keep it to the mailing lists and
> newsgroups.
> 
> and don't top post!
> 
> Sam
> 

Re: emacs-19.34 segfaults when built with Xfree 4.3.0 (glibc2.3.x,gcc 3.2)

[Thien-Thi Nguyen]

Hin-Tak Leung <hintak_leung@yahoo.co.uk> writes:

   but I would still like an answer, an explanation, or (gasp) a
   possible fix.

you are getting answers.  you are getting (oblique) explanations.  if
these are not to your liking, what adaptability can you demonstrate to
elicit the preferred results?

thi

Re: emacs-19.34 segfauls when built with Xfree 4.3.0 (glibc 2.3.x,gcc 3.2)

[Hin-Tak Leung]

(Sigh) A 3rd "See I am so helpful" post. Look - there is no
useful content in any of your three replies.

Other than my stated reason (an important old elisp script that
doesn't run under current versions), I think the memory foot-print
and launch-time could well be the reason for anybody wanting
to run emacs-19 or even earlier on current systems instead of the
current. As you say, it is a frequent-enough request, and I asked
a legitimate question that you fail to address anywhere close
in 3 posts...

Why can't you just try to answer a straight-forward question,
as you seem to suggest you "want to help"? As it turned out,
if I had mentioned cemacs (and mentioned that I don't want
to use MULE), I would be drawing myself into a
flame war regarding MULE's merits. That had seemed to be a
sensitive subject to some others (ttn@glug.org - who I believe
is possibly involved in MULE's development as I seems to have
come across that name in other projects). It is a fairly personal
choice - cemacs versus MULE, emacs 19 versus 21, and I don't really
need to explain why I prefer one to the other.

I asked a technical question and reported a possible bug
of an old unmaintained version of emacs, which I believe
some other people may like to continue to use for their own
reasons - those reasons are somewhat irrelevant to the question.
I would really prefer it to stay that way.

Sam Halliday wrote:
> Hin-Tak Leung wrote:
> 
>>Thanks for another "I am trying to help and I am not saying
>>anything" post...
> 
> 
> dude... i was trying to help initially... i know lots of people on
> mailing lists who for some reason or other like to run the latest and
> greatest linux kernel and gnu c libraries, but yet use whatever old
> program they can find (eg your old emacs) so it wasnt exactly a stupid
> thing to suggest you upgrade... if you described your system in so much
> detail, how come you managed to leave out the bit about cemacs!!!
> 
> i really dont give a shit if you start using xemacs... was that supposed
> to be some kind of lame threat, cuz it doesnt exactly scare me :-/
> 
> get a fuckin life,
> Sam
> 

Re: emacs-19.34 segfaults when built with Xfree 4.3.0(glibc2.3.x,gcc 3.2)

[Hin-Tak Leung]

(Sigh) This is getting more and more off-topic. You know, earlier posts
to similar questions (why does it segfault, "fatal error 11")
in the archive had instead concentrated
on the issue at hand e.g. in the archive around Jun 2002
there was an explicit patch (which I already use to get the
compilation going), and other people over the past 10 years' archive
had suggested running gdb on core dumps, doing a strace, etc on the
"Fatal Error 11" problem. So far neither you nor
"supposedly helpful" samuel had even suggested either gdb or strace.
or trying to get a core dump.

If you want my adaptability, I guess I would like to offer
a gdb back trace or something like that eventually, when
I get round to do it. Can you help debugging a gdb back trace?

(I would really like a straight forward "yes" or "no", rather
than going into further philosophical discussions).

Thien-Thi Nguyen wrote:
> Hin-Tak Leung <hintak_leung@yahoo.co.uk> writes:
> 
>    but I would still like an answer, an explanation, or (gasp) a
>    possible fix.
> 
> you are getting answers.  you are getting (oblique) explanations.  if
> these are not to your liking, what adaptability can you demonstrate to
> elicit the preferred results?
> 
> thi
> 

Re: emacs-19.34 segfaults when built with Xfree 4.3.0(glibc2.3.x,gcc 3.2)

[Thien-Thi Nguyen]

Hin-Tak Leung <hintak_leung@yahoo.co.uk> writes:

   So far neither you nor "supposedly helpful" samuel had even
   suggested either gdb or strace.  or trying to get a core
   dump.

it looks like you have stumbled upon this debugging approach on
your own, in any case, w/o needless prompting.  that's good to
see!

   If you want my adaptability, I guess I would like to offer
   a gdb back trace or something like that eventually, when
   I get round to do it. Can you help debugging a gdb back trace?

   (I would really like a straight forward "yes" or "no", rather
   than going into further philosophical discussions).

well i would really like to say "yes" or "no" straight-forwardly
rather than having to debug your PR problems first, but all i
can offer at this time are these questions: (1) how can anyone
definitively answer anything on something you have not yet
revealed?  (2) what is the root cause of any problem besides
philosophical misalignment of some sort?

thi

Re: emacs-19.34 segfaults when built with Xfree 4.3.0(glibc2.3.x,gcc 3.2)

[Hin-Tak Leung]

(Sigh). I would have been a lot happier if one of you had
replied with "get me a gdb back strace" than having to digress
to lengthy philosphical discussion on reasons to use an
older version, or resorting to foul languages.

As I said, I would prefer a "yes" or "no" to the gdb debug
question. It isn't to difficult to answer either:
(1) "possibly, depending on how deep the problem is; can't promise"
(2) "Sorry no, no eperience with gdb whatsoever"

But you are trying to draw into philosophical discussion again.
(I guess that's still better than the "get a f*cking life"
or "cheeky f*cker" replies)

I suppose the inclusion of MULE and breaking backward
compatibility is the root cause - and my not wanting to use it.
But this is somewhat irrelevant. Other people may have other
reasons for wanting to run an old copy of emacs on current
systems, and a solution may be useful to others. The
preference to use cemacs versus MULE may be a very
small minority, but I don't think the same can be said about
emacs 19 versus emacs 21 in general. In a way, MULE has
exactly the same strength and weakness as the general emacs
"Swiss Army Knife" philosophy: it is useful for linguists
who want to do a lot of languages within a single document,
but it doesn't work particularly well for any one given
language. And a 30MB MULE installation versus 50kB cemacs -
a trimmed emacs 19 installation in parallel/addition to
emacs 21 is only 10MB.

If I had sounded impatient, I had not resort to verbal
violence as some others did.

Thien-Thi Nguyen wrote:
> Hin-Tak Leung <hintak_leung@yahoo.co.uk> writes:
> 
>    So far neither you nor "supposedly helpful" samuel had even
>    suggested either gdb or strace.  or trying to get a core
>    dump.
> 
> it looks like you have stumbled upon this debugging approach on
> your own, in any case, w/o needless prompting.  that's good to
> see!
> 
>    If you want my adaptability, I guess I would like to offer
>    a gdb back trace or something like that eventually, when
>    I get round to do it. Can you help debugging a gdb back trace?
> 
>    (I would really like a straight forward "yes" or "no", rather
>    than going into further philosophical discussions).
> 
> well i would really like to say "yes" or "no" straight-forwardly
> rather than having to debug your PR problems first, but all i
> can offer at this time are these questions: (1) how can anyone
> definitively answer anything on something you have not yet
> revealed?  (2) what is the root cause of any problem besides
> philosophical misalignment of some sort?
> 
> thi
> 

Re: emacs-19.34 segfaults when built with Xfree 4.3.0(glibc2.3.x,gcc 3.2)

[Thien-Thi Nguyen]

Hin-Tak Leung <hintak_leung@yahoo.co.uk> writes:

   (Sigh). I would have been a lot happier if one of you had
   replied with "get me a gdb back strace" than having to digress
   to lengthy philosphical discussion on reasons to use an
   older version, or resorting to foul languages.

although it is encouraging that you know yourself well enough to say
this, i confess to not feeling comfortable ordering you about like an
employee.  these lengthy discussions surely would be better replaced by
some concrete information (as "concrete" as information can be ;-), it
seems you're saying.  the reasons for using this version (or any version
for that matter) are not really germaine to debugging the problem, you
also note.

   As I said, I would prefer a "yes" or "no" to the gdb debug
   question. It isn't to difficult to answer either:
   (1) "possibly, depending on how deep the problem is; can't promise"
   (2) "Sorry no, no eperience with gdb whatsoever"

what if some people on the list respond (1) and some people respond
(2) -- what have you gained and/or lost by this exercise?

   But you are trying to draw into philosophical discussion again.
   (I guess that's still better than the "get a f*cking life"
   or "cheeky f*cker" replies)

a personal quirk, no doubt: all discussion is philosophical to me, even
those involving hard bits of free software artifact (both pre- and post-
core dump ;-).

   If I had sounded impatient, I had not resort to verbal
   violence as some others did.

sometimes the sudden move is easy to interpret as both violent and
beautiful, and sometimes funny and sometimes sad.  where there is room
for interpretation there is room for misunderstanding (and bugs!).

thi

Re: emacs-19.34 segfaults when built with Xfree 4.3.0(glibc2.3.x,gcc 3.2)

[Hin-Tak Leung]

Here is the long awaited gdb back trace and strace. It seems to die
at the same place that emacs-21/AIX dies if it is run over a slow
dial-up connection (there were two different patches for that, one of
them by Mr Stallman himself no less, if I remember correctly)
- probably not related. Thought I'd mention this just in case.
==========================
 > gdb emacs-19.34
GNU gdb 5.3
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-slackware-linux"...
(gdb) run
Starting program: /usr/local/bin/emacs-19.34

Program received signal SIGSEGV, Segmentation fault.
0x400908b3 in XtInitializeWidgetClass () from /usr/X11R6/lib/libXt.so.6
(gdb) bt
#0  0x400908b3 in XtInitializeWidgetClass () from /usr/X11R6/lib/libXt.so.6
#1  0x400916a2 in _XtCreateWidget () from /usr/X11R6/lib/libXt.so.6
#2  0x400917c5 in XtCreateWidget () from /usr/X11R6/lib/libXt.so.6
#3  0x08075141 in x_window ()
#4  0x08076228 in Fx_create_frame ()
#5  0x080c65cb in Ffuncall ()
#6  0x080db3f3 in Fbyte_code ()
#7  0x080c6a8a in funcall_lambda ()
#8  0x080c64dc in Ffuncall ()
#9  0x080db3f3 in Fbyte_code ()
#10 0x080c6a8a in funcall_lambda ()
#11 0x080c64dc in Ffuncall ()
#12 0x080db3f3 in Fbyte_code ()
#13 0x080c6a8a in funcall_lambda ()
#14 0x080c64dc in Ffuncall ()
#15 0x080db3f3 in Fbyte_code ()
#16 0x080c6a8a in funcall_lambda ()
#17 0x080c64dc in Ffuncall ()
#18 0x080db3f3 in Fbyte_code ()
#19 0x080c6a8a in funcall_lambda ()
#20 0x080c687e in apply_lambda ()
#21 0x080c5564 in Feval ()
#22 0x0807fa43 in top_level_2 ()
#23 0x080c47ac in internal_condition_case ()
#24 0x0807fa80 in top_level_1 ()
#25 0x080c431b in internal_catch ()
#26 0x0807f9ae in command_loop ()
#27 0x0807f623 in recursive_edit_1 ()
#28 0x0807f6f8 in Frecursive_edit ()
#29 0x0807e5e5 in main ()
#30 0x40240bb4 in __libc_start_main () from /lib/libc.so.6
(gdb)
=================
The last few lines of strace:
=================
open("/usr/X11R6/lib/X11/icons/default/index.theme", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0755, st_size=27, ...}) = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0x401c3000
read(3, "[Icon Theme]\nInherits=core\n", 4096) = 27
close(3)                                = 0
munmap(0x401c3000, 4096)                = 0
--- SIGSEGV (Segmentation fault) ---
rt_sigaction(SIGSEGV, {SIG_DFL}, {0x807dbf0, [], SA_RESTART|0x4000000}, 8) = 0
getpgrp()                               = 11004
ioctl(0, 0x540f, [11004])               = 0
write(2, "Fatal error (11).", 17)       = 17
rt_sigaction(SIGIO, {SIG_IGN}, {0x80845b0, [], SA_RESTART|0x4000000}, 8) = 0
rt_sigprocmask(SIG_UNBLOCK, [SEGV 35 43 44 45 46 47 52 53 60 61], [SEGV], 8) = 0
getpid()                                = 11005
kill(11005, SIGSEGV)                    = 0
--- SIGSEGV (Segmentation fault) ---
+++ killed by SIGSEGV +++
================================

Thien-Thi Nguyen wrote:
> Hin-Tak Leung <hintak_leung@yahoo.co.uk> writes:
> 
>    (Sigh). I would have been a lot happier if one of you had
>    replied with "get me a gdb back strace" than having to digress
>    to lengthy philosphical discussion on reasons to use an
>    older version, or resorting to foul languages.
> 
> although it is encouraging that you know yourself well enough to say
> this, i confess to not feeling comfortable ordering you about like an
> employee.  these lengthy discussions surely would be better replaced by
> some concrete information (as "concrete" as information can be ;-), it
> seems you're saying.  the reasons for using this version (or any version
> for that matter) are not really germaine to debugging the problem, you
> also note.
> 
>    As I said, I would prefer a "yes" or "no" to the gdb debug
>    question. It isn't to difficult to answer either:
>    (1) "possibly, depending on how deep the problem is; can't promise"
>    (2) "Sorry no, no eperience with gdb whatsoever"
> 
> what if some people on the list respond (1) and some people respond
> (2) -- what have you gained and/or lost by this exercise?
> 
>    But you are trying to draw into philosophical discussion again.
>    (I guess that's still better than the "get a f*cking life"
>    or "cheeky f*cker" replies)
> 
> a personal quirk, no doubt: all discussion is philosophical to me, even
> those involving hard bits of free software artifact (both pre- and post-
> core dump ;-).
> 
>    If I had sounded impatient, I had not resort to verbal
>    violence as some others did.
> 
> sometimes the sudden move is easy to interpret as both violent and
> beautiful, and sometimes funny and sometimes sad.  where there is room
> for interpretation there is room for misunderstanding (and bugs!).
> 
> thi
> 

Re: emacs-19.34 segfauls when built with Xfree 4.3.0 (glibc 2.3.x,gcc 3.2)

[Sam Halliday]

Hin-Tak Leung <hintak_leung@yahoo.co.uk> wrote:
> (Sigh) A 3rd "See I am so helpful" post. Look - there is no
> useful content in any of your three replies.

they were not replies to the list... they were personal replies to you!
and were not intented for the list, so please remove me from your
CC's!!!

i offered help, you were a wanker about it... end of story. it had
NOTHING to do with the emacs mailing lists at that stage. now please
stop spamming me!

i apologise to all others on the list for this off topic email,

Sam

Re: emacs-19.34 segfauls when built with Xfree 4.3.0 (glibc 2.3.x,gcc 3.2)

[Hin-Tak Leung]

Languages... wonder what kind of school gives rise to these people.
(You bought shame on the whole *.hw.ac.uk domain...).

Sam Halliday wrote:
> Hin-Tak Leung <hintak_leung@yahoo.co.uk> wrote:
> 
>>(Sigh) A 3rd "See I am so helpful" post. Look - there is no
>>useful content in any of your three replies.
> 
> 
> they were not replies to the list... they were personal replies to you!
> and were not intented for the list, so please remove me from your
> CC's!!!
> 
> i offered help, you were a wanker about it... end of story. it had
> NOTHING to do with the emacs mailing lists at that stage. now please
> stop spamming me!
> 
> i apologise to all others on the list for this off topic email,
> 
> Sam
> 

Re: emacs-19.34 segfaults when built with Xfree 4.3.0(glibc2.3.x,gcc 3.2)

[Kai Großjohann]

Hin-Tak Leung <hintak_leung@yahoo.co.uk> writes:

> Program received signal SIGSEGV, Segmentation fault.
> 0x400908b3 in XtInitializeWidgetClass () from /usr/X11R6/lib/libXt.so.6
> (gdb) bt
> #0  0x400908b3 in XtInitializeWidgetClass () from /usr/X11R6/lib/libXt.so.6
> #1  0x400916a2 in _XtCreateWidget () from /usr/X11R6/lib/libXt.so.6

Interesting.  It dies deep inside the toolkit.

What happens if you compile Emacs without a toolkit?  (I'm trying to
find out if the toolkit is the problem.)
-- 
This line is not blank.

Re: emacs-19.34 segfauls when built with Xfree 4.3.0 (glibc 2.3.x,gcc 3.2)

[Eli Zaretskii]

> Date: Mon, 12 May 2003 18:29:50 +0100
> From: Hin-Tak Leung <hintak_leung@yahoo.co.uk>
> 
> I asked a technical question and reported a possible bug
> of an old unmaintained version of emacs, which I believe
> some other people may like to continue to use for their own
> reasons - those reasons are somewhat irrelevant to the question.
> I would really prefer it to stay that way.

Bugs (and a crash is a sign of a bug) should be reported to
gnu.emacs.bug, not to gnu.emacs.help.

I find it hard to believe you will find someone who will debug this
for you in such an old version of Emacs.

I looked thru etc/PROBLEMS and found there an entry about crashes at
startup when Emacs is built with XFree R6.4; there's a patch there for
Xlib, which perhaps will help you (assuming that PROBLEMS describes
the same problem there).

Re: Re: emacs-19.34 segfauls when built with Xfree 4.3.0 (glibc 2.3.x,gcc 3.2)

[Richard Stallman]

    That's a somewhat time-wasting question - if I am on linux with
    gcc 3.2 glibc 2.3.x and Xfree 4.3.0 most certainly the linux
    distribution I use come with a more recent version of emacs or xemacs.

If it contains those things, it appears to be a GNU/Linux
distribution, not a distribution of Linux alone.  See
http://www.gnu.org/gnu/gnu-linux-faq.html.

    Now back to my question: why emacs 19.34 segfault when built against
    glibc-2.3 and Xfree 4.3.0?

We're not maintaining Emacs 19.34 any more, because it is obsolete.
Other people are free to work on it if they want to.

In contrast,, we might be interested in trying to fix this problem

    I want to use a elisp script called cemacs (for Chinese inputs)
    but unfortunately the inclusion the MULE (Multi-lingual Extension)
    since version 20 has broken it.

if you send a bug report with a precise complete test case.

We are certainly interested in improving MULE.  Could you write to
emacs-devel@gnu.org and tell us why specifically MULE is not as good
as cemacs for your usage?

Re: emacs-19.34 segfauls when built with Xfree 4.3.0 (glibc 2.3.x,gcc 3.2)

[Hin-Tak Leung]

Yes, it is a GNU/Linux system.

As it turns out, the solution (adding '-z nocombreloc' to LDFLAGS)
fixes problem with building current version of emacs as well.

It is a problem with 'combreloc' becoming the default since March 2002 in
GNU ld so it affects very new GNU/Linux system when trying to build
all versions of emacs and xemacs, in addition to very new GNU/Hurd systems,
and any other system for which GNU ld is the default linker and for which the
version of GNU ld is less than 14 months old.

I'll address cemacs/MULE separately.

Richard Stallman wrote:
>     That's a somewhat time-wasting question - if I am on linux with
>     gcc 3.2 glibc 2.3.x and Xfree 4.3.0 most certainly the linux
>     distribution I use come with a more recent version of emacs or xemacs.
> 
> If it contains those things, it appears to be a GNU/Linux
> distribution, not a distribution of Linux alone.  See
> http://www.gnu.org/gnu/gnu-linux-faq.html.
> 
>     Now back to my question: why emacs 19.34 segfault when built against
>     glibc-2.3 and Xfree 4.3.0?
> 
> We're not maintaining Emacs 19.34 any more, because it is obsolete.
> Other people are free to work on it if they want to.
> 
> In contrast,, we might be interested in trying to fix this problem
> 
>     I want to use a elisp script called cemacs (for Chinese inputs)
>     but unfortunately the inclusion the MULE (Multi-lingual Extension)
>     since version 20 has broken it.
> 
> if you send a bug report with a precise complete test case.
> 
> We are certainly interested in improving MULE.  Could you write to
> emacs-devel@gnu.org and tell us why specifically MULE is not as good
> as cemacs for your usage?
> 

Re: emacs-19.34 segfaults when built with Xfree 4.3.0 (glibc2.3.x,gcc 3.2)

[Tomoyuki Murakami]

Hi all,

From: Hin-Tak Leung                                        
Subject: Re: emacs-19.34 segfaults when built with Xfree 4.3.0
            (glibc2.3.x,gcc 3.2)                                       
Date: Mon, 12 May 2003 23:11:46 +0100                               

> Here is the long awaited gdb back trace and strace. It seems to die
> at the same place that emacs-21/AIX dies if it is run over a slow
> dial-up connection (there were two different patches for that, one of
> them by Mr Stallman himself no less, if I remember correctly)
> - probably not related. Thought I'd mention this just in case.

The same core dump happens on my environment,
    FreeBSD 5.1R
    XFree86 4.3.0
    Emacs 21.3

So I would try debugging, re-configure XFree86 with  
   #define  DebugLibXt YES
on host.def, and linking debug-enabled libXt (libXt_d.a) to emacs.

And, then, the core dump does not happen any more !
I don't know why. 
It seems that static binary emacs doesn't crash at this point.

To make emacs statically,

$ CC="gcc -static" ./configure your-system-type ...

plus I needed CFLAGS="-DNO_ABORT" to avoid compile error.

----
Tomo.