3:31 p.m.
Georg Nikodym <georgn(a)Canada.Sun.COM> writes:
>>>>> "Hrvoje" == Hrvoje Niksic
<hniksic(a)srce.hr> writes:
Hrvoje> The thing is, I don't remember your reason for not wanting a
Hrvoje> clean 64bit compilation of XEmacs. What was it?
Hrvoje> I must be missing something.
The ratio of the difficulty in achieving a successful build to the
actual need for the thing.
Yes, but why the difficulty? XEmacs already compiles under 64-bit
IRIX and Digital UNIX.
Before you ask, my opinion on the lack of a need for a 64bit *macs
is largely premised on the relative scarcity of multi GB files to
around to edit.
True, but there are things for which large integers would be useful,
regardless of whether you edit large files. It seems sort of wasteful
to have the 64-bit ability in the hardware and OS, and XEmacs being
unable to use it.
Not that I'm trying to pressurize you into anything -- if you think
it's a waste of time, it's likely that someone else will do it. I was
just curious about the motives for not trying it.
--
Hrvoje Niksic <hniksic(a)srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
ED WILL NOT CORRUPT YOUR PRECIOUS BODILY FLUIDS!!
6:17 p.m.
New subject: Is 21.x going to be 64-bit clean?
>>>> "Hrvoje" == Hrvoje Niksic
<hniksic(a)srce.hr> writes:
Hrvoje> Yes, but why the difficulty? XEmacs already compiles under
Hrvoje> 64-bit IRIX and Digital UNIX.
Well for starters, configure fails. This failure is due the fact that
configure thinks it knows what its doing and feeds all sorts of -L and
-R arguments that are wrong in an LP64 build environment.
Once you've solved that problem, and realize that it's time for your
next meeting you throw up your hands.
But I still have a bit of time (yes, I'm doing this live) so lets
attempt a build...
Ignore lots of warnings (which is a particularly dangerous thing
moving to a 64bit world).
Oops, configure autodetected a 32 bit libaudio.a and attempted to link
it in. Reconfigure --with-sound=none.
The build gets to temacs and dies with:
EMACSBOOTSTRAPLOADPATH="/import/verve/georgn/xemacs/latest/src/../lisp/:/import/verve/georgn/xemacs/latest/5.8-sparc-64bit"
./temacs -batch -l /import/verve/georgn/xemacs/latest/src/../lisp/update-elc.el
Fatal error: assertion failed, file /import/verve/georgn/xemacs/latest/src/lisp.h, line
923, XGCTYPE (_obj) == Lisp_Type_Vector
Abort - core dumped
gmake[1]: *** [update-elc.stamp] Error 134
gmake[1]: Leaving directory
`/import/verve/georgn/xemacs/xemacs-21.0-b57/5.8-sparc-64bit/src'
gmake: *** [src] Error 2
Stack trace looks like:
program terminated by signal ABRT (Abort)
Current function is assert_failed
2608 abort ();
(/opcom/on28-tools/SUNWspro/SC5.x/bin/../WS5.0/bin/sparcv9/dbx) where
[1] _kill(0x0, 0x6, 0x0, 0x0, 0xffffffff, 0x8c32e0), at 0x7dba194c
[2] abort(0x7dcae6f8, 0x592500, 0x39b, 0x592530, 0x0, 0x0), at 0x7db4107c
=>[3] assert_failed(file = 0x100592500
"/import/verve/georgn/xemacs/latest/src/lisp.h", line = 923, expr = 0x100592530
"XGCTYPE (_obj) == Lisp_Type_Vector"), line 2608 in "emacs.c"
[4] error_check_vector(_obj = UNION), line 923 in "lisp.h"
[5] instantiate_image_instantiator(device = UNION, domain = UNION, instantiator = UNION,
pointer_fg = UNION, pointer_bg = UNION, dest_mask = 17), line 505 in "glyphs.c"
[6] image_instantiate(specifier = UNION, matchspec = UNION, domain = UNION, instantiator
= UNION, depth = UNION), line 2157 in "glyphs.c"
[7] primitive_funcall(fn = 0x1002f6728 =
&`temacs`glyphs.c`image_instantiate(Lisp_Object specifier, Lisp_Object matchspec,
Lisp_Object domain, Lisp_Object instantiator, Lisp_Object depth), nargs = 5, args =
0xffffffff7fffdb30), line 2862 in "eval.c"
[8] call_with_suspended_errors_1(opaque_arg = UNION), line 2061 in "eval.c"
[9] internal_catch(tag = UNION, func = 0x10015c268 =
&`temacs`eval.c`call_with_suspended_errors_1(Lisp_Object opaque_arg), arg = UNION,
threw = 0xffffffff7fffdaf4), line 1328 in "eval.c"
[10] call_with_suspended_errors(fun = 0x1002f6728 =
&`temacs`glyphs.c`image_instantiate(Lisp_Object specifier, Lisp_Object matchspec,
Lisp_Object domain, Lisp_Object instantiator, Lisp_Object depth), retval = UNION, class =
UNION, errb = RECORD, nargs = 5, ...), line 2169 in "eval.c"
[11] specifier_instance_from_inst_list(specifier = UNION, matchspec = UNION, domain =
UNION, inst_list = UNION, errb = RECORD, no_quit = 0, depth = UNION), line 2387 in
"specifier.c"
[12] specifier_instance(specifier = UNION, matchspec = UNION, domain = UNION, errb =
RECORD, no_quit = 0, no_fallback = 0, depth = UNION), line 2523 in
"specifier.c"
[13] recompute_one_cached_specifier_in_window(specifier = UNION, w = 0x100b52800), line
2742 in "specifier.c"
[14] recompute_all_cached_specifiers_in_window(w = 0x100b52800), line 2795 in
"specifier.c"
[15] Fset_window_buffer(window = UNION, buffer = UNION), line 3176 in
"window.c"
[16] allocate_frame_core(device = UNION), line 219 in "frame.c"
[17] Fmake_frame(props = UNION, device = UNION), line 377 in "frame.c"
[18] init_console_stream(), line 341 in "console-stream.c"
[19] xemacs_21_0_sparc_sun_solaris2_8(argc = 4, argv = 0xffffffff7fffe968, envp =
0xffffffff7fffe990, restart = 0), line 1624 in "emacs.c"
[20] main(argc = 4, argv = 0xffffffff7fffe968, envp = 0xffffffff7fffe990), line 2060 in
"emacs.c"
And before you know it's meeting time.
Hrvoje> True, but there are things for which large integers would be
Hrvoje> useful, regardless of whether you edit large files. It seems
Hrvoje> sort of wasteful to have the 64-bit ability in the hardware
Hrvoje> and OS, and XEmacs being unable to use it.
For instance? You'll excuse my lack of imagination. Besides which
64bit integer math is possible without growing the pointers...
Hrvoje> Not that I'm trying to pressurize you into anything -- if you
Hrvoje> think it's a waste of time, it's likely that someone else
Hrvoje> will do it. I was just curious about the motives for not
Hrvoje> trying it.
Not to worry, I'm not feeling pressured. I initially looked into this
out of curiousity and decided later I couldn't afford that
curiousity... I'll be happy to help someone with fewer motivational
impediments that me, though.
7:57 a.m.
New subject: Is 21.x going to be 64-bit clean?
Hrvoje Niksic writes:
| True, but there are things for which large integers would be useful,
| regardless of whether you edit large files. It seems sort of wasteful
| to have the 64-bit ability in the hardware and OS, and XEmacs being
| unable to use it.
Hm, a few days ago I tried to send a larger email[1] (~36MB) 21.x as
fragmented MIME message. Guess what it failed. Large integers are a
good thing to have but I would prefer XEmacs to handle data <4GB
correctly first.
[1] Don't argue this should be don't or not. It was a manager
decision.
8:24 a.m.
New subject: Is 21.x going to be 64-bit clean?
Marcus Thiessel writes:
Hrvoje Niksic writes:
| True, but there are things for which large integers would be useful,
| regardless of whether you edit large files. It seems sort of wasteful
| to have the 64-bit ability in the hardware and OS, and XEmacs being
| unable to use it.
Hm, a few days ago I tried to send a larger email[1] (~36MB) 21.x as
fragmented MIME message. Guess what it failed. Large integers are a
good thing to have but I would prefer XEmacs to handle data <4GB
correctly first.
How did it fail?
10:47 a.m.
New subject: Is 21.x going to be 64-bit clean?
Kyle Jones writes:
|
| How did it fail?
XEmacs reported a memory exhaust or fork failed which are to my mind
bogus since system resource shouldn't have been a problem.
BTW the problem happened to occur with VM and GNUS. So I don't think
the problem comes from these packages.
5:59 p.m.
New subject: Is 21.x going to be 64-bit clean?
Marcus Thiessel writes:
Kyle Jones writes:
|
| How did it fail?
XEmacs reported a memory exhaust or fork failed which are to my mind
bogus since system resource shouldn't have been a problem.
Two things to do: First, make sure your data segment size limit is
set as high as possible. For zsh and bash, use ulimit -a to check
resource limits. With csh and tcsh, use "limit". The second thing
to do is reconfigure/rebuild XEmacs with --use-minimal-tagbits=yes
so that XEmacs can use full 32-bit addresses and 31-bit integers.
7:14 a.m.
New subject: Is 21.x going to be 64-bit clean?
Kyle Jones writes:
| Two things to do: First, make sure your data segment size limit is
| set as high as possible. For zsh and bash, use ulimit -a to check
| resource limits.
I have a softlimit for data segment size of 1310720 kbytes which to be
enough or do 36MB attachment force XEmacs to grow that much.
| to do is reconfigure/rebuild XEmacs with --use-minimal-tagbits=yes
| so that XEmacs can use full 32-bit addresses and 31-bit integers.
That's my default anyway (--gung-ho).
9514
days inactive
9516
days old
6 comments
5 participants
participants (5)
-
Georg Nikodym -
Hrvoje Niksic -
Kyle Jones -
Marcus Thiessel -
Marcus Thiessel