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 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: Re: emacs-19.34 segfauls when built with Xfree 4.3.0 (glibc 2.3.x,gcc 3.2)

[Richard Stallman]

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

That is very strange.  The current version (21.3) contains code to use
those options automatically--see src/s/gnu-linux.h.  Can you debug why
this automatic mechanism failed to work for you?

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

[Hin-Tak Leung]

Richard Stallman wrote:
 >     As it turns out, the solution (adding '-z nocombreloc' to LDFLAGS)
 >     fixes problem with building current version of emacs as well.
 >
 > That is very strange.  The current version (21.3) contains code to use
 > those options automatically--see src/s/gnu-linux.h.  Can you debug why
 > this automatic mechanism failed to work for you?
 >

I have to apologise for jumping to conclusion on this. I saw the other
bug report against CVS with an almost identical set up (very up-to-date
system) and same symtome, (segfault in X, works alright in -nw, dies
in XtInitializeWidgetClass ()), but have not verified it being the
underlying cause on current CVS myelf. I will try to either confirm or
correct that when I get round to it.

On the other hand, there was a somewhat curious bahavior with 19.34.
    LDFLAGS=... ./configure
breaks, but
     export LDFLAGS=...
     ./configure
works. I know they are different and there is no reason why one should
work the same as the other. Nonetheless, mentioning this might be
a useful piece of info to somebody.

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

[Hin-Tak Leung]

Richard Stallman wrote:
>     As it turns out, the solution (adding '-z nocombreloc' to LDFLAGS)
>     fixes problem with building current version of emacs as well.
> 
> That is very strange.  The current version (21.3) contains code to use
> those options automatically--see src/s/gnu-linux.h.  Can you debug why
> this automatic mechanism failed to work for you?

Many Apologies, you are right - 21.3 does build correctly on my
system (GNU/Linux). But I also had a quick look around, and found that:

(a) the other bug report with that symptom (-nw ok, die at 
XtInitializeWidgetClass () in XFree86 4.3), filed against CVS emacs was
for x86-freebsd5.0. (oops).

(b) '-z nocombreloc' is set for gnu-linux, not for any of the other
system type or machine type. Shouldn't GNU/Hurd gets it as well,
as there is no other linker but GNU ld on GNU/Hurd?

(c) there doesn't seem to be any check for recent version (<14 months)
of GNU ld (where the precise problem is)? or indeed, the presence of
any version of GNU ld?

I believe it is possible to build gcc on freebsd (and many other
systems) '--with-gnu-ld'? How often this is done, I don't know -
it is probably not recommended to build gcc like that either. And I
have no idea which ld gcc's ./configure will pick by default if
GNU ld is somehow available in addition to the BSD one, but I
do know that if both gcc and another cc is available, emacs's
./configure picks gcc. It is possibly quite difficult to check
for exactly (c), because it is buried underneath gcc in how
it was built? Unfortunately the person who submitted that particular
bug report is no longer contactable, and there didn't seem to be
any follow up; but given he had Xfree86 4.3, his system would
have been quite recent otherwise, and it is not unthinkable that
he has a recent version of GNU ld.

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

[Andreas Schwab]

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

|> (c) there doesn't seem to be any check for recent version (<14 months)
|> of GNU ld (where the precise problem is)? or indeed, the presence of
|> any version of GNU ld?

There is no need for it.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

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

[Hin-Tak Leung]

Andreas Schwab wrote:
> Hin-Tak Leung <hintak_leung@yahoo.co.uk> writes:
> 
> |> (c) there doesn't seem to be any check for recent version (<14 months)
> |> of GNU ld (where the precise problem is)? or indeed, the presence of
> |> any version of GNU ld?
> 
> There is no need for it.

Why is that so? It isn't unthinkable that on a non-'GNU/Linux' system,
somebody installed a recent version of GNU binutils, and that
get used by gcc instead of the default ld, which in turn get used by
emacs. It is rare, I agree, and probably not worth the effort.

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

[Andreas Schwab]

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

|> Andreas Schwab wrote:
|> > Hin-Tak Leung <hintak_leung@yahoo.co.uk> writes:
|> > |> (c) there doesn't seem to be any check for recent version (<14
|> > months)
|> > |> of GNU ld (where the precise problem is)? or indeed, the presence of
|> > |> any version of GNU ld?
|> > There is no need for it.
|> 
|> Why is that so?

GNU ld has always ignored unknown -z options, so this works for every
version.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

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

[Hin-Tak Leung]

Andreas Schwab wrote:
> Hin-Tak Leung <hintak_leung@yahoo.co.uk> writes:
> 
> |> Andreas Schwab wrote:
> |> > Hin-Tak Leung <hintak_leung@yahoo.co.uk> writes:
> |> > |> (c) there doesn't seem to be any check for recent version (<14
> |> > months)
> |> > |> of GNU ld (where the precise problem is)? or indeed, the presence of
> |> > |> any version of GNU ld?
> |> > There is no need for it.
> |> 
> |> Why is that so?
> 
> GNU ld has always ignored unknown -z options, so this works for every
> version.

Oh, there is no need to detect the exact age/version of GNU ld. But my point
was, there is a small need to detect GNU ld versus BSD ld or other ld variants.

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

[Richard Stallman]

    (b) '-z nocombreloc' is set for gnu-linux, not for any of the other
    system type or machine type. Shouldn't GNU/Hurd gets it as well,
    as there is no other linker but GNU ld on GNU/Hurd?

Maybe so.

    (a) the other bug report with that symptom (-nw ok, die at 
    XtInitializeWidgetClass () in XFree86 4.3), filed against CVS emacs was
    for x86-freebsd5.0. (oops).

If someone who uses FreeBSD tells us what we need to do, we would
be glad to fix this.  Are you suggesting that Emacs should do
-z nocombreloc whenever it uses GNU LD?

    (c) there doesn't seem to be any check for recent version (<14 months)
    of GNU ld (where the precise problem is)? or indeed, the presence of
    any version of GNU ld?

I don't see any reason why we would want to check the version.

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

[Hin-Tak Leung]

Richard Stallman wrote:
> If someone who uses FreeBSD tells us what we need to do, we would
> be glad to fix this.  Are you suggesting that Emacs should do
> -z nocombreloc whenever it uses GNU LD?

Yes. According to GNU ld's changelog, 'combreloc' has become the
default since the 'March 2002' version, 14  months ago. So as
new GNU ld is being installed, or upgraded into systems which
is not GNU/linux (which alone has the fix), it is likely to
be a problem.

I do realise that distinguish GNU ld versus other ld might be
non-trivial to do...