May 1998 - XEmacs-Beta - XEmacs Mailing List Archives

Re: 21.0-b40-pre2: Success (and failure) under Solaris 2.5.1 26 years, 6 months

Oscar Figueiredo

>>>>> "Martin" == Martin Buchholz <martin(a)xemacs.org> writes: >>>>> "Damon" == Damon Lipparelli <lipp(a)primus.com> writes: Damon> My "debug" build (see the first "Installation" file above) failed. I got Damon> an unresolved symbol on error_check_ldap() from "eldap.o". The non-debug Damon> build succeeded. Martin> I've never done a --with-ldap build, but the problem is very likely Martin> fixed by: Martin> 1998-05-12 Martin Buchholz <martin(a)xemacs.org> Martin> * inline.c: Include eldap.h This was once done, then removed... and it certainly needs to be back again. Thanks Martin. Oscar

1 participants
0 comments

Re: XEmacs 20.4: find-function-noselect 26 years, 6 months

Jens-Ulrik Petersen

>>>>> "sb" == SL Baur <steve(a)xemacs.org> writes: sb> Jens-Ulrik Petersen <petersen(a)kurims.kyoto-u.ac.jp> writes: >> Actually it only does/did this for the recorded names of >> compiled functions, but you're right and I will fix this in the >> next version. sb> The calls to (compiled-function-annotation symbol) need to be sb> replaced with (symbol-file symbol), or to be backwards sb> compatible do an fboundp test on sb> `compiled-function-annotation' before calling it and using sb> `symbol-file' otherwise. Thanks, I didn't know about `symbol-file'. It will be in the next version. When was that introduced by the way? (Up to now I have been using `describe-symbol-find-file' which does much the same I think.) sb> There will be a 20.5 (Vinnie is back! :-) so backwards sb> compatibility is definitely still a hot issue. Ok. I hope the next version should work with earlier XEmacsen. >> However in XEmacs-21-beta with all function definitions now >> recorded in `load-history' the current version of that code is >> probably already redundant? sb> I don't think so. You'll still need to strip extensions. (My point was that that part of the code is only run in older XEmacsen.) Since (file-name-sans-extension ".emacs") => "", I am not using it yet for the main filename stripping. ME> (The real problem is that evaluating a defadvice form (via ME> eval-expression or similar) for a compiled file changes the ME> return value of (compiled-function-annotation def) to ME> "loadup.el".) >> It does? Can someone explain this to me in more detail. In my experience it used to take me to the advice rather than the original definition. However these days it takes me to the definition not the advice, since defadvice doesn't affect `load-history' as far as I know. Or am I missing something? sb> Yes. sb> As well anything evaluated in *scratch*, etc. Are you using the latest version of "find-func", Steve? I can't reproduce this. If I try to find the function `xdummy' that I defined in scratch I get the error: Don't know where `xdummy' is defined >> I am aware of problems of using `find-function' with adviced >> functions. It is mentioned in the to-do list: however I don't >> have a good solution for this. Again maybe this problem has >> also been solved in XEmacs-21-beta by `load-history'? sb> Unfortunately, no. I advise `save-buffers-kill-emacs' in sb> .emacs: sb> (symbol-file 'save-buffers-kill-emacs) => "~/.emacs" Again I can no longer reproduce this: see above. -- Jens-Ulrik Holger Petersen <http://www.kurims.kyoto-u.ac.jp/~petersen/> Research Institute for Mathematical Sciences, Kyoto University

1 participants
0 comments

Re: AIX compilation fixes 26 years, 6 months

Olivier Galibert

On Mon, May 11, 1998 at 11:31:09PM -0700, Martin Buchholz wrote: > 1998-05-11 Martin Buchholz <martin(a)xemacs.org> > > * aix4.h: Allow AIX 4.3 XEmacs to compile cleanly. > Unfortunately, the resulting temacs still cannot dump. What are the symptoms ? Do you have access to an aix box to test ? Does FSF emacs 20.2 work on it ? OG.

1 participants
0 comments

Re: size of XEmacs binary under Sparc/Solaris 2 26 years, 6 months

Jens-Ulrik Petersen

>>>>> "OG" == Olivier Galibert <galibert(a)pobox.com> writes: OG> On Wed, May 13, 1998 at 02:11:21PM +0900, Jens-Ulrik Petersen OG> wrote: > libXm.so.3 => /usr/dt/lib/libXm.so.3 > libXpm.so.4.8 => /usr/local/X11R6.1/lib/libXpm.so.4.8 > libXmu.so.6.0 => /usr/local/X11R6.1/lib/libXmu.so.6.0 >* libXt.so.6.0 => /usr/local/X11R6.1/lib/libXt.so.6.0 >* libXext.so.6.1 => /usr/local/X11R6.1/lib/libXext.so.6.1 >* libX11.so.6.1 => /usr/local/X11R6.1/lib/libX11.so.6.1 >* libSM.so.6.0 => /usr/local/X11R6.1/lib/libSM.so.6.0 >* libICE.so.6.0 => /usr/local/X11R6.1/lib/libICE.so.6.0 >* libXt.so.4 => /usr/openwin/lib/libXt.so.4 >* libX11.so.4 => /usr/openwin/lib/libX11.so.4 >* libSM.so.6 => /usr/openwin/lib/libSM.so.6 >* libICE.so.6 => /usr/openwin/lib/libICE.so.6 >* libXext.so.0 => /usr/openwin/lib/libXext.so.0 OG> Including two different versions on the same library can be OG> quite dangerous. Thanks for spotting that! I hadn't noticed that at all. How do I avoid this under dt/openwin. Should I remove "X11R6.1/" from the list of libraries (or "openwin/")? OG> You may have some static libraries included OG> too. A static motif library from the X11R6.1 directory maybe ? I don't know. OG> Just FYI (solaris 2.5.1) : OG> -rwxr-xr-x 1 galibert model 5187928 Mar 30 21:29 OG> xemacs-21.0-b33 Presumably this is without debugging info compiled in? OG> The ones you don't have (I guess you're non-mule) are: OG> png, jpeg, DtSvc, tt, dl, ucb, resolv and w I think I have png, jpeg statically linked in. No, I'm with mule. OG> You may want to look at your link phase if they are used or OG> not for you. Thanks. Fyi "Installation" follows. uname -a: SunOS orion 5.6 Generic sun4u sparc SUNW,Ultra-1 ../configure '--with-mule' '--with-gnu-make' '--with-tooltalk=no' '--with-sparcworks=no' '--with-cde=no' '--prefix=/proj2/lang/mule-unsupported' '--site-includes=/home/petersen/solaris/include' '--error-checking=all' '--gung-ho' '--site-runtime-libraries=/proj2/lang/mule-unsupported/solaris/lib:/usr/local/X11R6.1/lib:/usr/openwin/lib:/usr/dt/lib:/usr/local/lib' XEmacs 21.0-b40 "Saanen-pre2" configured for `sparc-sun-solaris2.6'. Where should the build process find the source code? /proj2/lang/mule-unsupported/src/xemacs-20 What installation prefix should install use? /proj2/lang/mule-unsupported What operating system and machine description files should XEmacs use? `s/sol2.h' and `m/sparc.h' What compiler should XEmacs be built with? gcc -g -O2 -Wall -Wno-switch Should XEmacs use the GNU version of malloc? yes 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/dt/include /usr/local/X11R6.1/include Where do we find X Windows libraries? /usr/dt/lib /usr/local/X11R6.1/lib Additional header files: /home/petersen/solaris/include Runtime library search path: /proj2/lang/mule-unsupported/solaris/lib:/usr/local/X11R6.1/lib:/usr/openwin/lib:/usr/dt/lib:/usr/local/lib Compiling in support for XAUTH. Compiling in support for XPM images. Compiling in support for X-Face message headers. Compiling in support for GIF image conversion. Compiling in support for JPEG image conversion. Compiling in support for PNG image conversion. Compiling in support for TIFF image conversion. Compiling in native sound support. Compiling in support for GNU DBM. Compiling in Mule (multi-lingual) support. Compiling in XIM (X11R5+ I18N input method) support. Using Motif to provide XIM support. Compiling in support for the WNN input method on Mule. Using WNN version 6. Compiling in support for OffiX. Compiling in support for Drag'n'Drop ( OffiX ). Compiling in support for proper session-management. Using Lucid menubars. Using Lucid scrollbars. Using Motif dialog boxes. Compiling in DLL support. movemail will use "dot-locking" for locking mail spool files. Using Lisp_Objects with minimal tagbits. Using indexed lrecord implementation. Compiling in extra code for debugging. Compiling in code for checking XEmacs memory usage. 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: --------------------------------------------------------- -- Jens-Ulrik Holger Petersen <http://www.kurims.kyoto-u.ac.jp/~petersen/> Research Institute for Mathematical Sciences, Kyoto University

2 participants
1 comments

Re: [Success] 21.0 "Saanen-pre2" XEmacs Lucid (beta40) on i386-pc-cyg win32 26 years, 6 months

SL Baur

Mike Hill <mikehill(a)hgeng.com> writes: > Sorry if some of you have seen this already. It bounced back from > xemacs-build-reports, so I guess I'm not correctly subscribed. You *do not* (or should not unless we've goofed) need to be subscribed to send reports there. For most of you, it's probably junk mail, which is why we're migrating it off of `xemacs-beta'.

1 participants
0 comments

Re: size of XEmacs binary under Sparc/Solaris 2 26 years, 6 months

Jens-Ulrik Petersen

>>>>> "MB" == Martin Buchholz <martin(a)xemacs.org> writes: >>>>> "juhp" == Jens-Ulrik Petersen <petersen(a)kurims.kyoto-u.ac.jp> writes: juhp> I am curious, can someone explain to me why for me XEmacs juhp> binaries built under Sparc/Solaris-2+gcc-2.8 are always so juhp> much larger than XEmacs binaries built under Intel/Linux? juhp> -rwxr-xr-x 1 petersen 19678112 May 13 13:37 solaris/bin/xemacs* juhp> I don't have the exact size of my Linux xemacs* binary but I juhp> seem to recall that it is of the order of 3+Mb. Why is the juhp> Solaris binary 5 times larger? MB> My previous posting to this mailing list suggested that MB> Solaris binaries should be just a little larger. MB> Linux, egcs 1.0.2, CFLAGS=-O2: 2314155 Linux, egcs 1.0.2, MB> CFLAGS=-O3: 2441153 MB> Solaris, egcs 1.0.2, CFLAGS=-O2: 2843084 Solaris, egcs 1.0.2, MB> CFLAGS=-O3: 2963692 MB> But I look at my debug builds, and they are almost as big as MB> yours: MB> Solaris, egcs 1.0.2, CFLAGS=-g: 18146604 MB> It is very likely to be debug information that is repeated in MB> all the .o files. Thanks Martin. I think that is the simple explanation I was looking for. I forget (to say) that I build XEmacs without debugging on my little i486 at home.... I didn't realize that debugging info makes such a huge difference in binary size. Cheers, -- Jens-Ulrik Holger Petersen <http://www.kurims.kyoto-u.ac.jp/~petersen/> Research Institute for Mathematical Sciences, Kyoto University

1 participants
0 comments

Re: size of XEmacs binary under Sparc/Solaris 2 26 years, 6 months

Didier Verna

Olivier Galibert <galibert(a)pobox.com> writes: > Including two different versions on the same library can be quite > dangerous. My solaris xemacs binray has duplicate libs too (mainly openwin and X11R6). It's not the only one ... nearly all of the apps I write have this too ! I've never understood why, and how this can work at all: libXt.so.5.0 => /usr/X11/lib/libXt.so.5.0 libXt.so.4 => /usr/openwin/lib/libXt.so.4 libXext.so.5.0 => /usr/X11/lib/libXext.so.5.0 libXext.so.0 => /usr/openwin/lib/libXext.so.0 libX11.so.5.0 => /usr/X11/lib/libX11.so.5.0 libX11.so.4 => /usr/openwin/lib/libX11.so.4 Can somebody give me an explanation ? Also I don't like the presence of libucb. Why is it needed ? -- / / _ _ Didier Verna http://www.inf.enst.fr/~verna/ - / / - / / /_/ / E.N.S.T. INF C214 mailto:verna＠inf.enst.fr /_/ / /_/ / /__ / 46 rue Barrault Tel. (33) 01 45 81 80 72 75634 Paris cedex 13 Fax. (33) 01 45 81 31 19

1 participants
0 comments

Re: [Success] 21.0 "Russian White" XEmacs Lucid (beta39) on i386-pc-c ygwin32 26 years, 6 months

SL Baur

Adrian Aichner <aichner(a)ecf.teradyne.com> writes: > I've made a note of the new mailing list and a future version of > build-report will probably offer a choice whether to send to > xemacs-beta (mainly to ask for help) or to xemacs-beta-reports (mainly > for those boring reports starting out with [Success]) ;-> > Any suggestions? That sounds good to me.

1 participants
0 comments

Re: Packaging -- yet another confused person 26 years, 6 months

Michael Sperber

>>>>> "Stephen" == Stephen J Turnbull <turnbull(a)sk.tsukuba.ac.jp> writes: Stephen> Keyword alert! "CVS". There has consistently been a bad interaction Stephen> with CVS's default behavior and packages. When was the last time? That should have been fixed for a while now. >>>>> "ms" == Michael Sperber <sperber(a)informatik.uni-tuebingen.de> writes: ms> Beats me. Stephen> Pity, that. You are the only indexed documentation we have.... I didn't mean to be rude. What I meant is: The code hasn't changed at all since b38, so I suggest there's something else in the environment that's changed. -- Cheers =8-} Chipsy Friede, Völkerverständigung und überhaupt blabla

1 participants
0 comments

Re: [problem] generating autoloads for mule-base/ethio-util.el 26 years, 6 months

SL Baur

Stephen J Turnbull <turnbull(a)sk.tsukuba.ac.jp> writes: >>>>>> "juhp" == Jens-Ulrik Petersen <petersen(a)kurims.kyoto-u.ac.jp> writes: juhp> It looks like "mule-base/ethio-util.el" has been corrupted? No, just rename it to something other than *.el, how about ethio-util.EL? > No, I bet it's fine in the FSF's Emacs. Probably. > I'll check later. XEmacs Mule does not understand Ethiopic, > evidently. So the strings of ISO-2022 control sequences are just > ASCII strings, and Ethiopic makes liberal use of ?" in encoding > characters. > Unterminated strings, and BLAM! Yup. > These files should be removed from mule-base until XEmacs has been > taught about Ethiopic. They were put back in by request by people who wished to hack on them. Renaming them (temporarily until they work) so they don't get picked up by autoloads generation is a reasonable compromise. I've renamed thus: $ mv ethio-util.el ethio-util.EL $ mv ethiopic.el ethiopic.EL $ mv vietnamese.el vietnamese.EL

1 participants
0 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 May 1998