3:23 p.m.
Hi,
Did just update to RH8.0 and got gcc 3.2 plus of course a lot of other
updates here and there ;-)
This makes the build of latest 2.4.10 and 2.5 crash due to a segv
during the dump stage. This is the backtrace for the 21.5 build.
......................................................................
[...]
#0 0x42028cc1 in kill () from /lib/i686/libc.so.6
(gdb) backtrace
#0 0x42028cc1 in kill () from /lib/i686/libc.so.6
#1 0x080ec7bb in fatal_error_signal (sig=11) at emacs.c:3424
#2 <signal handler called>
#3 0x0829618f in intern_int (str=0x8340575 "init-locale-at-early-startup")
at symbols.c:193
#4 0x081d5a17 in init_intl () at intl.c:173
#5 0x080ea52e in xemacs_21_5_b9_i686_pc_linux (argc=5, argv=0xbffff884,
envp=0xbffff89c, restart=0) at emacs.c:2209
#6 0x080eb1de in main () at emacs.c:2783
#7 0x420158d4 in __libc_start_main () from /lib/i686/libc.so.6
(gdb)
......................................................................
Now it is quiet likely that there is something wrong here in
environment due to the update. So are there any known problems with
using gcc 3.2 for xemacs or should I be looking into my libs for
problems? Any suggestions?
Yours
--
%% Mats
5 p.m.
>>>> "Mats" == Mats Lidell
<matsl(a)contactor.se> writes:
Mats> Hi,
Mats> Did just update to RH8.0 and got gcc 3.2 plus of course a lot of other
Mats> updates here and there ;-)
Mats> Now it is quiet likely that there is something wrong here in
Mats> environment due to the update. So are there any known problems with
Mats> using gcc 3.2 for xemacs or should I be looking into my libs for
Mats> problems? Any suggestions?
I have used gcc3.2 for a while now (gentoo-1.4) and it didn't give me
any errors with xemacs. I also did an upgrade, but I think most of the
libs are now gcc3.2-style. So, at least I'd say: look into your libs ;-).
Bye, Adam.
--
Adam Duck (duck(a)cs.uni-frankfurt.de)
Bockenheimer Landstr. 135 / Zi. 211
60325 Frankfurt/Main
______________________________________
Klingon multitasking systems do not support "time-sharing". When a
Klingon program wants to run, it challenges the scheduler in
hand-to-hand combat and owns the machine.
--- Klingon Programmer
5:02 p.m.
On Wed, 2002-10-02 at 17:23, Mats Lidell wrote:
Did just update to RH8.0 and got gcc 3.2 plus of course a lot of
other
updates here and there ;-)
So did I...
This makes the build of latest 2.4.10 and 2.5 crash due to a segv
during the dump stage. This is the backtrace for the 21.5 build.
...but I didn't see that (only tried with 21.4.10 RC1). How did you
configure? Here's how I did it:
uname -a: Linux bobcat.ods.org 2.4.18-14 #1 Wed Sep 4 13:35:50 EDT 2002 i686 i686 i386
GNU/Linux
./configure 'i686-redhat-linux-gnu' '--prefix=/usr'
'--exec-prefix=/usr' '--bindir=/usr/bin' '--datadir=/usr/share'
'--libdir=/usr/lib' '--mandir=/usr/share/man/man1'
'--infodir=/usr/share/info' '--with-gpm=no' '--with-sound=native'
'--with-pop' '--mail-locking=lockf' '--with-clash-detection'
'--with-mule=yes' '--use-union-type' '--with-database=berkdb'
'--with-ldap=yes' '--with-hesiod=no' '--with-canna=yes'
'--with-wnn=yes' '--with-widgets=motif' '--with-menubars=lucid'
'--with-scrollbars=lucid' '--with-dialogs=motif' '--with-xim=xlib'
'--with-msw=no' '--with-xfs=yes' '--pdump' '--debug=no'
'--error-checking=none'
XEmacs 21.4.10 "Military Intelligence (RC1)" configured for
`i686-redhat-linux'.
Compilation / Installation:
Source code location: /home/scop/rpm/BUILD/xemacs-21.4.10
Installation prefix: /usr
Operating system description file: `s/linux.h'
Machine description file: `m/intel386.h'
Compiler: gcc -O2 -march=i686
Relocating allocator for buffers: no
GNU version of malloc: yes
- Using Doug Lea's new malloc from the GNU C Library.
Window System:
Compiling in support for the X window system:
- X Windows headers location: /usr/X11R6/include
- X Windows libraries location: /usr/X11R6/lib
- Handling WM_COMMAND properly.
Using Lucid menubars.
Using Lucid scrollbars.
Using Motif dialog boxes.
Using Motif native widgets.
TTY:
Compiling in support for ncurses.
Images:
Compiling in support for GIF images (builtin).
Compiling in support for XPM images.
Compiling in support for PNG images.
Compiling in support for JPEG images.
Compiling in support for TIFF images.
Sound:
Compiling in support for sound (native).
Databases:
Compiling in support for Berkeley database.
Compiling in support for LDAP.
Compiling in support for PostgreSQL.
- Using PostgreSQL header file: libpq-fe.h
- Using PostgreSQL V7 bindings.
Internationalization:
Compiling in support for Mule (multi-lingual Emacs).
Compiling in support for XIM (X11R5+ I18N input method).
- Using raw Xlib to provide XIM support.
- Using XFontSet to provide bilingual menubar.
Compiling in support for Canna on Mule.
Compiling in support for the WNN input method on Mule.
Mail:
Compiling in support for POP mail retrieval.
Compiling in support for "lockf" mail spool file locking method.
Other Features:
Inhibiting IPv6 canonicalization at startup.
Compiling in support for dynamic shared object modules.
Using the union type for Lisp_Objects.
Using the new portable dumper.
--
\/ille Skyttä
ville.skytta at xemacs.org
5:39 p.m.
Ville Skyttä <ville.skytta(a)xemacs.org> writes:
On Wed, 2002-10-02 at 17:23, Mats Lidell wrote:
> Did just update to RH8.0 and got gcc 3.2 plus of course a lot of other
> updates here and there ;-)
So did I...
Question: will XEmacs compiled on 7.x run on 8.0? We have several Red
Hat machines running various versions (7.0, 7.1, 7.2, 7.3) sharing an
XEmacs installation. I would like to throw 8.0 in that mix and hope
that it too can run the shared installation of XEmacs.
-Nevin
6:09 p.m.
On Wed, 02 Oct 2002 12:39:27 EDT, Nevin Kapur <nevin(a)jhu.edu> said:
Question: will XEmacs compiled on 7.x run on 8.0? We have several
Red
Hat machines running various versions (7.0, 7.1, 7.2, 7.3) sharing an
XEmacs installation. I would like to throw 8.0 in that mix and hope
that it too can run the shared installation of XEmacs.
Haven't beat on it severely, but I didn't have any programs break going to 8.0
(except for some self-inflicted damage). Biggest gotcha I hit was that
my nvidia drivers needed a 'insmod -f' rather than 'modprobe', since the
upgraded insmod command pisses and moans that the kernel was compiled with gcc3
and the module with gcc2. Feel free to ignore it - I've been running that way
for months. ;)
/Valdis
8:54 p.m.
On Wednesday, 2 October 2002, Nevin Kapur wrote:
Ville Skyttä <ville.skytta(a)xemacs.org> writes:
> On Wed, 2002-10-02 at 17:23, Mats Lidell wrote:
>
>> Did just update to RH8.0 and got gcc 3.2 plus of course a lot of other
>> updates here and there ;-)
>
> So did I...
Question: will XEmacs compiled on 7.x run on 8.0? We have several Red
Hat machines running various versions (7.0, 7.1, 7.2, 7.3) sharing an
XEmacs installation. I would like to throw 8.0 in that mix and hope
that it too can run the shared installation of XEmacs.
It should unless you built it with Xaw3d. XEmacs uses C and nobody is going
to change the binary compatibility of C programs. Otherwise a lot of people
will be pissed.
-kitty.
--
Krishnakumar B <kitty at cs dot wustl dot edu>
Distributed Object Computing Laboratory, Washington University in St.Louis
9:52 p.m.
Krishnakumar B <kitty(a)cse.wustl.edu> writes:
On Wednesday, 2 October 2002, Nevin Kapur wrote:
[...]
> Question: will XEmacs compiled on 7.x run on 8.0? We have
several Red
> Hat machines running various versions (7.0, 7.1, 7.2, 7.3) sharing an
> XEmacs installation. I would like to throw 8.0 in that mix and hope
> that it too can run the shared installation of XEmacs.
It should unless you built it with Xaw3d. XEmacs uses C and nobody is going
to change the binary compatibility of C programs.
Confirmed. I just upgraded a machine to 8.0 and it runs our shared
installation of XEmacs just fine (so far).
-Nevin
2:45 a.m.
>>>> "Krishnakumar" == Krishnakumar B
<Krishnakumar> writes:
Krishnakumar> XEmacs uses C and nobody is going to change the
Krishnakumar> binary compatibility of C programs. Otherwise a lot
Krishnakumar> of people will be pissed.
Being Red Hat means never having to say you're sorry! :-)
Seriously, though, the binutils people did just that with the Hannibal
Lecter ld, and we had problems with global constructors in C (no "++")
under gcc at one point. (unexec, again; I think pdump would have made
htat irrelevant just as it made Hannibal cry.)
--
Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
My nostalgia for Icon makes me forget about any of the bad things. I don't
have much nostalgia for Perl, so its faults I remember. Scott Gilbert c.l.py
2:57 a.m.
On Thursday, 3 October 2002, Stephen J. Turnbull wrote:
>>>>> "Krishnakumar" == Krishnakumar B
<Krishnakumar> writes:
Krishnakumar> XEmacs uses C and nobody is going to change the
Krishnakumar> binary compatibility of C programs. Otherwise a lot
Krishnakumar> of people will be pissed.
Being Red Hat means never having to say you're sorry! :-)
Stephen, I think the long-term approach which will help XEmacs as a whole
is to get them to ship the packages we want them to ship with the settings
that are preferred by the XEmacs developers. Doing a search in my beta
folder turned up more RedHat crashes than any other OS. That is something
we can't change as then it would amount to telling what to run.
I don't think that it should be difficult. I think that if we ship a RPM
spec that works fine with a RedHat system then it will help immensely. We
can just point users to do rpm -bt XEmacs-21.4.x.tar.gz. Instead of asking
them to figure out things like binutils etc. Even better would be to ship
pre-built RPMs like we do on Windows.
Being the maintainer (I forget which one: the beta or the gamma :-), you can
try telling them and ask if they will co-operate. Nothing wrong in
trying...
Seriously, though, the binutils people did just that with the
Hannibal
Lecter ld, and we had problems with global constructors in C (no "++")
under gcc at one point. (unexec, again; I think pdump would have made
htat irrelevant just as it made Hannibal cry.)
I thought it is just a problem with building XEmacs from scratch. ld
started merging data sections into one (prevented with -fno-common, IIRC)
or does it also affect already built versions ?
-kitty.
PS: I just found out that Xaw3d which ships with RedHat 8.0 was built with
-DUSE_ARROW_SCROLLBAR. Waiting for the fun to start on comp.emacs.
--
Krishnakumar B <kitty at cs dot wustl dot edu>
Distributed Object Computing Laboratory, Washington University in St.Louis
5:30 a.m.
>>>> "Krishnakumar" == Krishnakumar B
<Krishnakumar> writes:
Krishnakumar> I think that if we ship a RPM spec
Er, that's Red Hat's job. They get _paid_ to do it.
Krishnakumar> that works fine with a RedHat system
Good trick. Do you know _why_ Red Hat turns up more often in crash
reports than any other Linux? Because Red Hat is in the business of
being incompatible (they spell it "b-e-t-t-e-r") and regularly tweaks
the environment in ways that break programs. They pay a large staff
of package maintainers to do nothing but ensure that all distributed
programs work ... and even so, Red Hat has trouble doing that! We
don't have time or expertise to do better.
If you want something that "works fine with Red Hat", get it from Red
Hat. If you want up-to-date code, get it from XEmacs. If you want
both, lobby Red Hat to pay more attention to XEmacs---they have the
resources, and will apply them if they think there's enough customer
demand. Debian `sid' lags by only a couple of weeks at most ... and
they provide {gnome, nogtk} X {mule, nomule} variations (at least).
Ville Skyttä does send spec patches to Red Hat, and occasionally
announces availability of his personal build as RPMs. I think that's
about right. We may formalize that in the binary-kits download area.
As for the rpm -bt trick, that's not going to happen in any release I
manage, unless it's a lot more sophisticated than it sounds. It must
work correctly for multiple versions of Red Hat, not to mention SuSE
and Mandrake. I think the right way to handle that is the way Debian
does, with a separate file that contains the necessary control
information. Eg, in
etc/contrib/{redhat,debian,mandrake,suse,aix,solaris,freebsd,...}/
Pick your poison, untar it, and run the build tool.
Krishnakumar> I thought it is just a problem with building XEmacs
Krishnakumar> from scratch. ld started merging data sections into
Krishnakumar> one (prevented with -fno-common, IIRC) or does it
Krishnakumar> also affect already built versions ?
The ld problem manifests as a build-time problem. I don't recall the
details of the constructor problem, that was probably build-time only.
However, I did have a dynamic linking problem with codasrv recently
because of upgrades to glibc---the only way to assure runtime
compatibility is 100% static linking.
--
Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
My nostalgia for Icon makes me forget about any of the bad things. I don't
have much nostalgia for Perl, so its faults I remember. Scott Gilbert c.l.py
1:12 p.m.
I tried Mandrake 9.0 which ships with xemacs-21.4.9 (yeah!) but I
don't think they configured it right. Info doesn't work.
1:22 p.m.
New subject: Problems with `distro-du-jour'
>>>> "Neal" == Neal D Becker
<nbecker(a)hns.com> writes:
Neal> I tried Mandrake 9.0 which ships with xemacs-21.4.9 (yeah!)
Neal> but I don't think they configured it right. Info doesn't
Neal> work.
Feel free to M-x report-emacs-bug, and a rpm --list-installed-files
(however you say that in RPM).
Does info work from the command line? XEmacs's default configuration
definitely doesn't conform to FHS, so I bet they put the info files in
/usr/share/info or so, and neglected to fix the build config.
--
Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
My nostalgia for Icon makes me forget about any of the bad things. I don't
have much nostalgia for Perl, so its faults I remember. Scott Gilbert c.l.py
6:49 p.m.
It works for you because you are using pdump. Try without.
andy
-----Original Message-----
From: xemacs-beta-admin(a)xemacs.org
[mailto:xemacs-beta-admin＠xemacs.org]On Behalf Of Ville Skyttä
Sent: Wednesday, October 02, 2002 9:02 AM
To: Mats Lidell
Cc: xemacs-beta(a)xemacs.org
Subject: Re: Problems with gcc 3.2
On Wed, 2002-10-02 at 17:23, Mats Lidell wrote:
> Did just update to RH8.0 and got gcc 3.2 plus of course a lot of other
> updates here and there ;-)
So did I...
> This makes the build of latest 2.4.10 and 2.5 crash due to a segv
> during the dump stage. This is the backtrace for the 21.5 build.
...but I didn't see that (only tried with 21.4.10 RC1). How did you
configure? Here's how I did it:
uname -a: Linux bobcat.ods.org 2.4.18-14 #1 Wed Sep 4 13:35:50
EDT 2002 i686 i686 i386 GNU/Linux
./configure 'i686-redhat-linux-gnu' '--prefix=/usr'
'--exec-prefix=/usr' '--bindir=/usr/bin' '--datadir=/usr/share'
'--libdir=/usr/lib' '--mandir=/usr/share/man/maan1'
'--infodir=/usr/share/info' '--with-gpm=no'
'--with-sound=native'
'--with-pop' '--mail-locking=lockf' '--with-clash-detection'
'--with-mule=yes' '--use-union-type' '--with-database=berkdb'
'--with-ldap=yes' '--with-hesiod=no' '--with-canna=yes'
'--with-wnn=yes' '--with-widgets=motif' '--with-menubars=lucid'
'--with-scrollbars=lucid' '--with-dialogs=motif'
'--with-xim=xlib' '--with-msw=no' '--with-xfs=yes'
'--pdump'
'--debug=no' '--error-checking=none'
XEmacs 21.4.10 "Military Intelligence (RC1)" configured for
`i686-redhat-linux'.
Compilation / Installation:
Source code location: /home/scop/rpm/BUILD/xemacs-21.4.10
Installation prefix: /usr
Operating system description file: `s/linux.h'
Machine description file: `m/intel386.h'
Compiler: gcc -O2 -march=i686
Relocating allocator for buffers: no
GNU version of malloc: yes
- Using Doug Lea's new malloc from the GNU C Library.
Window System:
Compiling in support for the X window system:
- X Windows headers location: /usr/X11R6/include
- X Windows libraries location: /usr/X11R6/lib
- Handling WM_COMMAND properly.
Using Lucid menubars.
Using Lucid scrollbars.
Using Motif dialog boxes.
Using Motif native widgets.
TTY:
Compiling in support for ncurses.
Images:
Compiling in support for GIF images (builtin).
Compiling in support for XPM images.
Compiling in support for PNG images.
Compiling in support for JPEG images.
Compiling in support for TIFF images.
Sound:
Compiling in support for sound (native).
Databases:
Compiling in support for Berkeley database.
Compiling in support for LDAP.
Compiling in support for PostgreSQL.
- Using PostgreSQL header file: libpq-fe.h
- Using PostgreSQL V7 bindings.
Internationalization:
Compiling in support for Mule (multi-lingual Emacs).
Compiling in support for XIM (X11R5+ I18N input method).
- Using raw Xlib to provide XIM support.
- Using XFontSet to provide bilingual menubar.
Compiling in support for Canna on Mule.
Compiling in support for the WNN input method on Mule.
Mail:
Compiling in support for POP mail retrieval.
Compiling in support for "lockf" mail spool file locking method.
Other Features:
Inhibiting IPv6 canonicalization at startup.
Compiling in support for dynamic shared object modules.
Using the union type for Lisp_Objects.
Using the new portable dumper.
--
\/ille Skyttä
ville.skytta at xemacs.org
8:17 a.m.
>>>> Andy wrote:
Andy> It works for you because you are using pdump. Try without. andy
(Do you have some more info about this that you are not telling us
about?)
Anyway I tried _with_ -pdump and then it passed the dump phase and I got
a working XEmacs (I have just started so no extensive tests yet.)
I use a very simple setup, ./configure --with-mule -pdump, on a RH8.0
upgraded system.
Could someone please have an idea why the normal dump phase crashes
due to a SEGV but the -pdump works and seems to produce something that
works. Environmental problem with my upgraded system or what?
Yours
--
%% Mats
10:22 a.m.
>>>> "Mats" == Mats Lidell
<matsl(a)contactor.se> writes:
Mats> Could someone please have an idea why the normal dump phase
Mats> crashes due to a SEGV but the -pdump works and seems to
Mats> produce something that works.
This is why pdump is so desirable.
Mats> Environmental problem with my upgraded system or what?
unexec has to have incestuous knowledge of what ld does. If ld
changes (eg, the -z combreloc, AKA Hannibal Lecter, feature), unexec
loses hard.
pdump, OTOH, basically amounts to implementing a special-purpose ld
(ie, it only knows how to link Lisp data together), bypassing the
details of the system ld altogether.
--
Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
My nostalgia for Icon makes me forget about any of the bad things. I don't
have much nostalgia for Perl, so its faults I remember. Scott Gilbert c.l.py
8:02 a.m.
|--==> "ML" == Mats Lidell <matsl(a)contactor.se> writes:
ML> Now it is quiet likely that there is something wrong here in
ML> environment due to the update. So are there any known problems with
ML> using gcc 3.2 for xemacs or should I be looking into my libs for
ML> problems? Any suggestions?
I build 21.5 regularly with gcc 3.3 without problem.
--
|---<Steve Youngs>---------------<GnuPG KeyID: 10D5C9C5>---|
| XEmacs - It's not just an editor. |
| It's a way of life. |
|------------------------------------<youngs(a)xemacs.org>---|
8082
days inactive
8087
days old
15 comments
10 participants
participants (10)
-
Adam Duck -
Andy Piper -
Krishnakumar B -
Mats Lidell -
Neal D. Becker -
Nevin Kapur -
Stephen J. Turnbull -
Steve Youngs -
Valdis Kl=?iso8859-4?Q?=BA?=tnieks -
Ville Skyttä