January 1999 - XEmacs-Beta - XEmacs Mailing List Archives

Re: Are there still problems compiling ldap.el ? 26 years

Oscar Figueiredo

>>>>> "sb" == SL Baur <steve(a)xemacs.org> writes: sb> Oscar Figueiredo <Oscar.Figueiredo(a)di.epfl.ch> writes in xemacs-beta(a)xemacs.org: >> Some time ago, Martin brought to my attention that ldap.el failed to >> compile in XEmacs 21.2 due to max-lisp-eval-depth being exceeded somewhere. sb> ... >> Is someone still affected or has the problem mysteriously vanished ? sb> Checking for Mule support...Yes sb> Compiling files without .elc... sb> /devel/xemacs/xemacs-21.2/src/xemacs -batch -vanilla -f batch-byte-compile lisp/./ldap.el sb> Compiling /devel/xemacs/xemacs-21.2/lisp/ldap.el... sb> While compiling toplevel forms in file /devel/xemacs/xemacs-21.2/lisp/ldap.el: sb> !! error (("Lisp nesting exceeds `max-lisp-eval-depth'")) sb> Done I can't reproduce this at the moment. I am trying a build with Mule to see if it makes a difference. Is it possible for you to try a build --with-ldap=yes ? (you need LDAP libraries of course) In fact ldap.el is useless in a non LDAP-enabled XEmacs, therefore there's no point in trying to compile it in this case. Is there a means to avoid that ? Oscar

1 participants
0 comments

Status of gdbsrc.el 26 years

Charles G Waldman

What is the status of gdbsrc.el? It's in the CVS package sources under prog/debug but not listed in the Makefile.

1 participants
0 comments

Re: Are there still problems compiling ldap.el ? 26 years

SL Baur

Oscar Figueiredo <Oscar.Figueiredo(a)di.epfl.ch> writes in xemacs-beta(a)xemacs.org: > Some time ago, Martin brought to my attention that ldap.el failed to > compile in XEmacs 21.2 due to max-lisp-eval-depth being exceeded somewhere. ... > Is someone still affected or has the problem mysteriously vanished ? Checking for Mule support...Yes Compiling files without .elc... /devel/xemacs/xemacs-21.2/src/xemacs -batch -vanilla -f batch-byte-compile lisp/./ldap.el Compiling /devel/xemacs/xemacs-21.2/lisp/ldap.el... While compiling toplevel forms in file /devel/xemacs/xemacs-21.2/lisp/ldap.el: !! error (("Lisp nesting exceeds `max-lisp-eval-depth'")) Done uname -a: Linux demeter.xemacs.org 2.2.0-pre4 #2 SMP Sun Jan 3 01:50:20 PST 1999 i686 unknown ./configure '--cflags=-mpentiumpro -O6 -fno-exceptions' '--error-checking=none' '--debug=no' '--with-mule=yes' '--with-dialogs=athena3d' '--with-scrollbars=athena3d' '--use-union-type=no' '--with-xim=xlib' '--with-xfs' '--mail-locking=file' '--extra-verbose=no' XEmacs 21.2-b8 "Artemis" configured for `i686-pc-linux'. Where should the build process find the source code? /devel/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 -mpentiumpro -O6 -fno-exceptions 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 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. Using XFontSet to provide bilingual menubar. Compiling in support for Canna on Mule. Compiling in support for proper session-management. Using Lucid menubars. Using Athena-3d scrollbars. Using Athena-3d dialog boxes. Compiling in DLL support. movemail will use "dot-locking" for locking mail spool files. Using Lisp_Objects with minimal tagbits.

1 participants
0 comments

Are there still problems compiling ldap.el ? 26 years

Oscar Figueiredo

Some time ago, Martin brought to my attention that ldap.el failed to compile in XEmacs 21.2 due to max-lisp-eval-depth being exceeded somewhere. I downloaded the latest 21.2 sources from CVS and compiled on Solaris 2.5.1 with and without LDAP and could not reproduce the problem: - in the build with LDAP support: ldap.el compiled fine - in the build without LDAP support: ldap.el failed to compile due to the missing builtin LDAP support ((require 'ldap) fails at the beginning). Is someone still affected or has the problem mysteriously vanished ? Oscar

1 participants
0 comments

Re: help fixing backup-dir.el and auto-save.el for NT 26 years

SL Baur

Glynn Clements <glynn(a)sensei.co.uk> writes in xemacs-beta(a)xemacs.org: ... > On Linux (at least), a particular filesystem (mount point) may be FAT, > VFAT or NTFS (currently read-only, but read-write may eventually be > available), The description of read/write NTFS in the Linux 2.2 pre-release kernels was changed from "Experimental" to "Dangerous" a few days ago, so I suspect it won't be any time soon.

1 participants
0 comments

Re: *DO* dynamically link distributed executables 26 years

SL Baur

Stephen J Turnbull <turnbull(a)sk.tsukuba.ac.jp> writes in xemacs-beta(a)xemacs.org: mb> Maybe Linux didn't do as good a job on the backward mb> compatibility mechanism for shared libraries as Solaris did? > _Don't_ get us started. ;-) Too late! > At present, basically it's the problem that the Linux libc was nowhere > near a vanilla GNU libc until libc.so.6 came out. This upgrade broke > just about every existing binary. The libc5 -> glibc-2.0 aka libc6 upgrade only broke binaries that used -rpath -- which suddenly had a hardcoded path to incompatible libraries: $ emacs-19.34 zsh: 945 segmentation fault (core dumped) emacs-19.34 $ The source changes broke just about everything, but that's a different issue. The glibc-2.0 to glibc-2.1 upgrade appears (at this time) to only break old C++ binaries. This unfortunately means unrecompilable stuff like the Real Audio player and Star Office 5.0, to name two requires a careful little dance to get working[1]. > For the future, Linux does not have the option of making its own > decisions about the backward compatiblity vs functionality tradeoff. > That's in the hands of GNU.... Which is one reason why the need will > be around for a while. If we could take the GNU out of "linux-gnu" we would be much better off. I'm grateful for the software, but the FSF doesn't know diddly about putting together whole functional systems. I find it sadly ironic that the hardest part about maintaining a Do-It-Yourself Linux distribution is overcoming FSF architectural fuckage. Footnotes: [1] You have to have glibc-2.0.7 libraries in a separate directory and you have to run the ELF interpreter directly. My real audio wrapper looks like: #! /bin/sh LD_LIBRARY_PATH=/home/steve/glibc-2.0.7 LD_PRELOAD=/usr/lib/Real/libnblock.so /lib/ld-2.0.7.so /usr/bin/rvplayer.LIBC6 $＠ This also contains the run-time workaround for the binary incompatibility in the Linux 2.2 kernel which changes/"fixes" the semantics of non-blocking I/O on sound devices.

1 participants
0 comments

help fixing backup-dir.el and auto-save.el for NT 26 years

Greg Klanderman

Hello all, I just started to use NT, and have the current 21.0 beta. What's the right way to check whether you're running on Windows? I see that I can use (console-type), but I really want to know if the file system is NT, not the window system. Someday it may be possible to have an X console from an XEmacs running on NT. Anyway, I'll send patches for backup-dir and auto-save once answered. thanks, greg (please copy me on replies; I'm on neither list)

2 participants
1 comments

Re: *DO* dynamically link distributed executables 26 years

SL Baur

Martin Buchholz <martin(a)xemacs.org> writes in xemacs-beta(a)xemacs.org: >>>>>> "Rick" == Rick Campbell <rick(a)campbellcentral.org> writes: Rick> For a variety of reasons, at least on some platforms -- Linux in Rick> particular -- it's come down to there being a real need for seperate Rick> static and non-static builds. My suspicion is that that need will Rick> still be around for a while. > Maybe Linux didn't do as good a job on the backward compatibility > mechanism for shared libraries as Solaris did? Not particularly. There has been roughly one incompatible libc upgrade per year and a half since I've been using it. The braindamaged way -rpath is implemented (and/or used) is the major problem I've had. Every binary that *does not* link with -rpath handles upgrades. Every binary that uses it breaks on an upgrade. Some idiot has just broken libtool so that using it will force -rpath into link command lines and that's going to cause a whole new round of breakage for the transition glibc-2.0 -> glibc-2.1.

1 participants
0 comments

Re: error in Help menu 26 years

SL Baur

Richard Coleman <coleman(a)math.gatech.edu> writes in xemacs-beta(a)xemacs.org: > This is for XEmacs-21.0.61 on FreeBSD 2.2.6. > After starting with "xemacs -vanilla", if I click on the menu entry > Help/About Emacs > I get the error > Wrong type argument: sequencep, 21 > I'm using my XEmacs-20.4 setup for my packages, by symlinking > xemacs-packages -> xemacs-20.4 Can you get a Lisp stack backtrace? You have libpng linked in, right?

1 participants
0 comments

Re: copyright.el 26 years

SL Baur

Andreas Jaeger <aj(a)arthur.rhein-neckar.de> writes in xemacs-beta(a)xemacs.org: >>>>>> Eric Eide writes: Eric> "Andreas" == Andreas Jaeger <aj(a)arthur.rhein-neckar.de> writes: Andreas> Emacs 19.34 (the only one I've got access to) comes with a Andreas> file copyright.el for updating the copyright strings in Andreas> e.g. GNU programs. I can't find it in any of the XEmacs Andreas> packages. Eric> In XEmacs 20.4, the equivalent is `upd-copyr.el'. The FSF Eric> `copyright.el' is apparently a rewrite of `upd-copyr.el'; see Eric> the comments in `upd-copyr.el'. O.K. I remember that now. > I didn't know that. But the problem is that it disappeared from > XEmacs 21.0. It got moved in 20.5-beta7 "Appenzell". There is a CHANGES-beta entry. > A find over the whole XEmacs-package and XEmacs core > sources didn't reveal anything. The file must have been lost (or was > this intentional, I couldn't find a ChangeLog entry either) when > creating the packages.:-( It probably ought to be left out at this point and replaced with a ported copyright.el.

1 participants
0 comments

2025

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 January 1999