June 1999 - XEmacs-Beta - XEmacs Mailing List Archives

Re: ldap fails with utf-8 error 25 years, 5 months

SL Baur

Oscar Figueiredo <oscar(a)xemacs.org> writes in xemacs-beta(a)xemacs.org: > I will probably send a patch to default `ldap-coding-system' to nil > instead until UTF-8 support becomes more convenient to use. That would be best. -- 窓番号を入力してください

1 participants
0 comments

Re: ldap fails with utf-8 error 25 years, 5 months

SL Baur

Raymond Toy <toy(a)rtp.ericsson.se> writes in xemacs-beta(a)xemacs.org: >>>>>> "Jan" == Jan Vroonhof <vroonhof(a)math.ethz.ch> writes: Jan> You are running under Mule are you? If then you need the ucs-conv Jan> package and you need to (require 'ucs-conv). This loads the necessary Jan> tables for Unicode support > Yep. I didn't have the ucs-conv package. (I thought xemacs sumo and > xemacs mule sumo had everything, but apparently not.) ucs-conv isn't officially supported and it looks like it may never be as real UTF-8 internal support is well on its way and will appear soon on an FTP site near you ... I would suggest not using it in the meantime. -- 窓番号を入力してください

1 participants
0 comments

SIGSEGV in faces customisation 21.2-b15 "Sakuragawa" 25 years, 5 months

Peter B. West

Installation is attached. With debug-on-error and debug-on-signal set t, attempts to access either of the menu items Options > Customize > Face... or Options > Edit Faces... followed by the selection of the default `all' results in the generation of the customise buffer, and the message Creating customization buffer... done at which point stillness descends. I can go away for a cup of tea, and when I move the mouse, xemacs dumps core - no backtrace. The core is no more helpful. When I run gdb -c core xemacs-beta I am informed that the program terminated with a SEGV. `where' gives me #0 0x0 in ?? () I know nothing about gdb, as may be obvious, but I was under the impression that `where' would tell me something about, well, where. Is there any way I can extract more information about this thing? xemacs-beta is a link to src/xemacs, as compiled on June 9, from a cvs update of a day or two before. (I have since done another update without a compile, so I can't say just when.) Yours faithfully, -- __ /__ Peter B. West p.west(a)uq.net.au / http://www.uq.net.au/~zzpwest / "Lord, to whom shall we go?" uname -a: Linux zzpwest.dialin.uq.net.au 2.2.5-15 #4 Thu May 27 22:38:41 EST 1999 i586 unknown ./configure '--cflags=-g -O3 -DENABLE_COMPOSITE_CHARS' '--with-mule' '--with-png=yes' '--debug' '--memory-usage-stats' '--rel-alloc' XEmacs 21.2-b15 "Sakuragawa" configured for `i586-pc-linux'. Where should the build process find the source code? /opt3/src/xemacs/xemacs-21.2 What installation prefix should install use? /usr/local What operating system and machine description files should XEmacs use? `s/linux.h' and `m/intel386.h' What compiler should XEmacs be built with? gcc -g -O3 -DENABLE_COMPOSITE_CHARS Should XEmacs use the GNU version of malloc? yes (Using Doug Lea's new malloc from the GNU C Library.) Should XEmacs use the relocating allocator for buffers? yes What window system should XEmacs use? x11 Where do we find X Windows header files? /usr/X11/include Where do we find X Windows libraries? /usr/X11/lib Compiling in support for XAUTH. Compiling in support for XPM images. Compiling in support for PNG image handling. Compiling in support for (builtin) GIF image handling. Compiling in support for JPEG image handling. Compiling in support for TIFF image handling. Compiling in support for X-Face message headers. Compiling in native sound support. Compiling in support for Berkeley DB. Compiling in support for GNU DBM. Compiling in support for ncurses. Compiling in support for GPM (General Purpose Mouse). Compiling in Mule (multi-lingual) support. Compiling in XIM (X11R5+ I18N input method) support. Using raw Xlib to provide XIM support. Compiling in support for proper WM_COMMAND handling. Using Lucid menubars. Using Lucid scrollbars. Using Motif dialog boxes. Compiling in DLL support. movemail will use "dot-locking" for locking mail spool files. Compiling in extra code for debugging. WARNING: --------------------------------------------------------- WARNING: Compiling in support for runtime error checking. WARNING: XEmacs will run noticeably more slowly as a result. WARNING: Error checking is on by default for XEmacs beta releases. WARNING: ---------------------------------------------------------

1 participants
0 comments

XEmacs is not 64-bit clean (was Re: Build failure, xemacs-21.1.2 on rh6-based linux-alpha-unknown) 25 years, 5 months

SL Baur

Greg Badros <gjb(a)cs.washington.edu> writes in xemacs-beta(a)xemacs.org: >> > I looked at src/xemacs-- it's u+x bit is not set, and it is a large >> > file that is just a big hole on disk (reads as all NULLs). Urgh. There are known problems with XEmacs on DEC Alpha using OSF. If you have a temacs, cd to the src directory and run `make run-temacs'. Does that work? > Ok, thanks for your help. Xemacs did build w/o many problems on Intel, > so it's definitely an issue only on my Alpha box. XEmacs is *not* 64 bit clean. On DEC OSF, temacs and dumped xemacs are semi-functional, but some internals are broken, definitely including the character sets/character category tables. The following illustrates what might be part of the problem: => (expt 2 62) -4611686018427387904 => (1- (expt 2 62)) 4611686018427387903 => (+ 0 (1- (expt 2 62))) -1 => (1- (1- (expt 2 62))) 4611686018427387902 => (- (1- (expt 2 62)) 1) -2 $ cat /tmp/sizeof.c main() { printf("sizeof (int) = %d\n", sizeof (int)); printf("sizeof (unsigned int) = %d\n", sizeof (unsigned int)); printf("sizeof (long) = %d\n", sizeof (long)); printf("sizeof (unsigned long) = %d\n", sizeof (unsigned long)); printf("sizeof (void *) = %d\n", sizeof (void *)); } $ gcc -o /tmp/sizeof /tmp/sizeof.c $ /tmp/sizeof sizeof (int) = 4 sizeof (unsigned int) = 4 sizeof (long) = 8 sizeof (unsigned long) = 8 sizeof (void *) = 8 $ cc -o /tmp/sizeof.DECCC /tmp/sizeof.c $ /tmp/sizeof.DECCC sizeof (int) = 4 sizeof (unsigned int) = 4 sizeof (long) = 8 sizeof (unsigned long) = 8 sizeof (void *) = 8 -- 窓番号を入力してください

1 participants
0 comments

Re: Build failure, xemacs-21.1.2 on rh6-based linux-alpha-unknown 25 years, 5 months

Jan Vroonhof

Kyle Jones <kyle_jones(a)wonderworks.com> writes: > Oh no, please, not the aliasing stuff again. I thought > this idea died back when ANSI C was still a draft. Well it is alive, kicking and in will be switched on by default in gcc 2.95. Jan

3 participants
2 comments

Re: Build failure, xemacs-21.1.2 on rh6-based linux-alpha-unknown 25 years, 5 months

Greg J. Badros

Vin Shelton <acs(a)xemacs.org> writes: > What version of gcc/egcs are you using? Does the option -fno-strict-aliasing > help? egcs-2.91.66 (the one that came w/ Redhat 6.0 -- should I build a more recent one?) I tried with --cflags="-O2 -fno-strict-aliasing" and the make ends after: "Building finder database ... /bin/sh: /home/gjb/xemacs-21.1.2/src/xemacs: cannot execute binary file I looked at src/xemacs-- it's u+x bit is not set, and it is a large file that is just a big hole on disk (reads as all NULLs). Any further suggestions? Anyone out there build for alpha linux boxes? Thanks, Greg

2 participants
1 comments

Re: Build failure, xemacs-21.1.2 on rh6-based linux-alpha-unknown 25 years, 5 months

Greg J. Badros

Vin Shelton <acs(a)xemacs.org> writes: > gjb(a)cs.washington.edu said: > > I tried with --cflags="-O2 -fno-strict-aliasing" and the make ends > > after: > > > "Building finder database ... /bin/sh: /home/gjb/xemacs-21.1.2/src/ > > xemacs: cannot execute binary file > > > I looked at src/xemacs-- it's u+x bit is not set, and it is a large > > file that is just a big hole on disk (reads as all NULLs). > > I have no more suggestions. I was really just taking a shot in the dark (and, > as it turns out, causing panic in the streets). I'm guessing your problem is > alpha-specific. It seems like dumping didn't work. Did you say temacs works, > but only in -batch mode? Perhaps one of the alpha mavens can offer some > suggestions. Ok, thanks for your help. Xemacs did build w/o many problems on Intel, so it's definitely an issue only on my Alpha box. Maybe I'll try grabbing a newer egcs and see if it makes any difference... I need to upgrade it sooner or later, anyway. Thanks, Greg

1 participants
0 comments

Re: Build failure, xemacs-21.1.2 on rh6-based linux-alpha-unknown 25 years, 5 months

Jan Vroonhof

Hrvoje Niksic <hniksic(a)srce.hr> writes: > > Oh no, please, not the aliasing stuff again. I thought this idea > > died back when ANSI C was still a draft. > > What are you all talking about? This GCC options will be the default in GCC 2.95 and above -fstrict-aliasing Allows the compiler to assume the strictest aliasing rules applicable to the language being compiled. For C (and C++), this activates optimizations based on the type of expressions. In particular, an object of one type is assumed never to reside at the same address as an object of a different type, unless the types are almost the same. For example, an unsigned int can alias an int, but not a void* or a double. A character type may alias any other type. Pay special attention to code like this: union a_union { int i; double d; }; int f() { a_union t; t.d = 3.0; return t.i; } The practice of reading from a different union member than the one most recently written to (called "type-punning") is common. Even with `-fstrict-aliasing', type-punning is allowed, provided the memory is accessed through the union type. So, the code above will work as expected. However, this code might not: int f() { a_union t; int* ip; t.d = 3.0; ip = &t.i; return *ip; } Basically this changes the interpretation of "implementation defined" in GCC from "for some reason ANSI didn't codify the normal Unix C thing to do but we will do it anyway" to "screw you". This setting breaks for instance the Linux networking code which plays all kinds of pointer tricks. The thread on the egcs mailing lists contains such gems as "C is not a portable assembly language anymore", "simply use unions", "everybody has fixed their code already because other compilers have been doing this optimization for ages" etc Given the fact our typing system does use C as a low level assembly language, I am worried. I hope that these worries are unjustified. Jan

1 participants
0 comments

Re: Build failure, xemacs-21.1.2 on rh6-based linux-alpha-unknown 25 years, 5 months

Hrvoje Niksic

Kyle Jones <kyle_jones(a)wonderworks.com> writes: > Jan Vroonhof writes: > > Vin Shelton <acs(a)xemacs.org> writes: > > > > > What version of gcc/egcs are you using? Does the option > > > -fno-strict-aliasing > > > > So I am not the only one who is scared by the discussions on the > > egcs lists. > > Oh no, please, not the aliasing stuff again. I thought this idea > died back when ANSI C was still a draft. What are you all talking about?

1 participants
0 comments

Re: Build failure, xemacs-21.1.2 on rh6-based linux-alpha-unknown 25 years, 5 months

Jan Vroonhof

Vin Shelton <acs(a)xemacs.org> writes: > What version of gcc/egcs are you using? Does the option -fno-strict-aliasing So I am not the only one who is scared by the discussions on the egcs lists. Jan

2 participants
1 comments

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

XEmacs-Beta June 1999