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)

[Sam Halliday]

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)

[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 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 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 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...

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

[Hin-Tak Leung]

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.

I had an older binary which was compiled by gcc 2.95.x against
Xfree 4.1(?) and glibc-2.1 (maybe 2.0?) which still works on
this current system.


#uname -a
Linux pc7221 2.4.20 #2 Wed Apr 23 08:44:11 BST 2003 i686 unknown

#cat /var/log/XFree86.log
XFree86 Version 4.3.0
Release Date: 27 February 2003
X Protocol Version 11, Revision 0, Release 6.6
Build Operating System: Linux 2.4.20 i686 [ELF]

# gcc -v
Reading specs from /usr/lib/gcc-lib/i386-slackware-linux/3.2.2/specs
Configured with: ../gcc-3.2.2/configure --prefix=/usr --enable-shared 
--enable-threads=posix --enable-__cxa_atexit --disable-checking --with-gnu-ld 
--verbose --target=i386-slackware-linux --host=i386-slackware-linux
Thread model: posix
gcc version 3.2.2