October 2000 - XEmacs-Beta - XEmacs Mailing List Archives

Re: [fyoung@anytimenow.com] compilation-find-file bug (xemacs-base 1.42) (PR#1394) 24 years, 1 month

Gunnar Evermann

nbecker(a)fred.net writes: > I don't know about the fix, but I have experienced this same bug - > it's rather nasty. Could you please test the fix? (remember to re-bytecompile the fle). thanks Gunnar

2 participants
1 comments

Re: [sumner@graphics.lcs.mit.edu] Faces wrong when opening new frame (PR#1465) 24 years, 1 month

Alexander G. Burchell

>>>>> "Gunnar" == Gunnar Evermann <ge204(a)eng.cam.ac.uk> writes: Gunnar> I'm having faces trouble in xemacs and I'm hoping someone Gunnar> can help. I just spent several hours and there seems to Gunnar> be a weird bug/feature. Hopefully I'm just making a Gunnar> mistake. Gunnar> When I upgraded to version 21.1.12 of xemacs I started Gunnar> having a problem with my syntax coloring. When I open a Gunnar> file from the command prompt like this: Gunnar> xemacs main.C Gunnar> then everything is fine and the colors display as I've set Gunnar> them in my .emacs file. However, after emacs is running Gunnar> and I open a new file using C-x 5 f (or meta-x Gunnar> find-file-other-frame) the new file has the wrong colors. Gunnar> All the syntax is highlighed with some default set of Gunnar> colors that are totally different than the ones I chose. I hate to say, "me too", but ... "me too". Here is the installation (it is the precompiled XEmacs with Mule features): uname -a: SunOS ashanti 5.7 Generic i86pc i386 i86pc /home/jason/wk/XEMACS/admin/binary-kits/21.1/solaris-kits/build/xemacs-src/configure 'i386-pc-solaris2.7' '--prefix=/usr/local' '--bindir=/usr/local/bin/i386-pc-solaris2.7-mule' '--site-includes=/usr/local/include' '--site-libraries=/usr/local/lib/xemacs-static' '--with-gnu-make' '--without-gcc' '--cflags=-v -xstrconst -mr -Qn -xO4 -xdepend -xlibmil' '--with-menubars=lucid' '--with-scrollbars=lucid' '--with-dialogs=motif' '--with-xpm' '--with-xface' '--with-tooltalk' '--with-gif' '--with-png' '--with-jpeg' '--with-database=dbm' '--with-cde=no' '--with-workshop=no' '--with-mule=yes' '--with-canna' XEmacs 21.1-p3 "Acadia" configured for `i386-pc-solaris2.7'. Where should the build process find the source code? /home/jason/wk/XEMACS/admin/binary-kits/21.1/solaris-kits/build/xemacs-src What installation prefix should install use? /usr/local What operating system and machine description files should XEmacs use? `s/sol2.h' and `m/intel386.h' What compiler should XEmacs be built with? cc -v -xstrconst -mr -Qn -xO4 -xdepend -xlibmil 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/openwin/include Where do we find X Windows libraries? /usr/dt/lib /usr/openwin/lib Additional header files: /usr/local/include Additional libraries: /usr/local/lib/xemacs-static Runtime library search path: /usr/ccs/lib:/usr/dt/lib:/usr/openwin/lib:/opt/SUNWdt/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 X-Face message headers. Compiling in support for 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 Canna on Mule. Compiling in support for ToolTalk. 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. Thanks, -- Alexander Burchell Wilshire Associates aburchel(a)wilshire.com (310) 899-2303

2 participants
1 comments

Re: Failure to build 21.2.b36 in W2K 24 years, 1 month

Adrian Aichner

>>>>> "Peter" == Peter G Martin <peter(a)access.com.au> writes: Peter> Adrian Aichner wrote: >> >> Matthew> COMPLETE! But who the hell screwed up the references to >> >> Matthew, don't you think you're a bit offensive in your choice of >> language? >> What is your current directory when you run >> nmake ... -f ...xemacs.mak? Peter> ^^^^ Peter> Now look who's talking dirty ! To answer in your favorite language: warn "I'll be darned" if ("-f ..." eq "-f..."); :-) Peter> --peter(a)access.com.au -- Peter G. Martin, Peter> Tech writer, Perl Thingy-er, pmartin1(a)bigpond.net.au -- Adrian Aichner <adrian(a)xemacs.org>, http://www.xemacs.org

1 participants
0 comments

Re: [CRASH] in -nw mode / image specifiers 24 years, 1 month

Gunnar Evermann

Didier Verna <didier(a)xemacs.org> writes: > I can't run "XEmacs -nw" within gdb Why not? I do that all the time. You can even return to the gdb prompt with C-g. Gunnar

1 participants
0 comments

auto-save-unslashify-name/auto-save-slashify-name at WinNT is broken 24 years, 1 month

Konstantin Malakhanov

This bug report will be sent to the XEmacs Development Team, not to your local site managers!! Please write in English, because the XEmacs maintainers do not have translators to read other languages for them. In XEmacs 21.2 (beta35) "Nike" [Lucid] (i586-pc-win32) of Fri Sep 08 2000 on NEVERYON configured using `configure UNKNOWN' I get an error during auto-saving if I set auto-save-directory to some NT directory. To store the whole path in the file name, auto-save-name-in-fixed-directory uses auto-save-unslashify-name to replace \\ in file path by \\\\. But this doesn't work for WinNT, as backslahes are not allowed in file name at any case. This work for storing auto-save files in the original directory (with auto-save-directory nil), as in this case backslashes are part of the path and not of the file name. Maybe with auto-save-directory set, backslashes should be replaced by any other unusual character, like vertical bar? -- Konstantin Malakhanov ISOWARE GmbH, Feithstr. 142, 58097 Hagen, Germany email: km(a)isoware.de Tel: 02331/8019-71 FAX: 02331/8019-99

1 participants
0 comments

Re: Finder and packages. 24 years, 1 month

Nickolay Pakoulin

Martin Buchholz <martin(a)xemacs.org> writes: > An outstanding message. You have clearly identified the problem, come > up with a clean design of the solution, and are implementing it. Thanks for your compliment ;)). > I > hope we include your changes as soon as you think they are ready. > > Very happy, > > Martin Ok. I hope to finish it this week. Nick.

1 participants
0 comments

Re: Not linking so many things to the lib-src stuff? 24 years, 1 month

Karl M. Hegbloom

>>>>> "Martin" == Martin Buchholz <martin(a)xemacs.org> writes: >>>>> "Karl" == Karl M Hegbloom <karlheg(a)bittersweet.inetarena.com> writes: Karl> All of the "lib-src" binaries aside from the `gnus*' are compiled Karl> with ${ldflags} on the CC line. ${ldflags} is built using Karl> ${ld_libs_general}, which looks like: Karl> ld_libs_general=-ldl -ldb -lgpm -lncurses -L/usr/lib -lesd -laudiofile -lm -lpq -lldap -llber -lm -lutil -lgcc -lc -lgcc /usr/lib/crtn.o Martin> Oh, you're complaining about the non-X libs used only for the xemacs Martin> executable, and not necessary for the utils. In that case, a much Martin> more complex patch is called for. For everything in configure.in that Martin> gets added to LIBS, sometimes automatically via AC_CHECK_LIB, that Martin> code will have to be reconsidered, and either add them to some new Martin> variable xemacs_special_libs, or to general_libs. I just don't think Martin> this optimization is worth it, in general. It would make all future Martin> maintenance of configure.in more difficult. No; it's not that difficult. I have a patch for "lib-src/Makefile.in.in" already; and am thinking of one for "configure.in" to fix the formation of ＠libs_xauth＠. If there is only a static libXau, then that's all that needs to be linked, I think... I need to spend more time on this though; I want to make sure that this is really the case. Perhaps the libXau.a really does need things in the other X libraries. ??? You tell me and we'll both know; I can UTSL tomorrow afternoon. Martin> Your time would be better spent improving the linker so that future Martin> generations of hackers don't have to deal with this. Perhaps. Martin> If you can prove that none of the apps in lib-src will *ever* need Martin> anything other than libc, we can drop ld_libs_general from the link Martin> lines completely. However, I don't think you can do that. Certainly Martin> gnuserv needs X, and various other programs will need libs like Martin> -lsocket. Ah. -lsocket is on Solaris and others? I don't think Linux needs that, does it? That complicates things and invalidates my patch. Martin> This optimization is going to cause everyone a world of pain to maintain. Martin> For your own use as a debian hacker, it's very simple. Build as Martin> usual, then something like Martin> cd lib-src; make clean; make ld_libs_general= ; Ok. Martin> Or you could build in such a way that the special libraries are linked Martin> statically. I recommend this anyways. Martin> Untested: Martin> LIBS='-Bstatic -ldb -lgpm -lncurses -L/usr/lib -lesd -laudiofile -lm -lpq -lldap -llber -lm -lutil -Bdynamic' configure && make Martin> You can even put this in a wrapper script that calls configure and make. Nah. The first way is better, for now. Smaller binaries. Karl> I will submit a patch and ChangeLog to the patch queue shortly. Martin> I enjoy your enthusiasm very much, but I'm inclined to reject most Martin> patches. I am willing to give you access to my development Martin> environment, where I have many machines for you to test with... Martin> Breaking SunOS 4, for example, is not acceptable. Sounds fun. I'd enjoy that. Martin> Start with ctags. You might be able to prove that it only uses stuff Martin> from libc, but I want something close to proof, not just that we'll Martin> fix the other platforms as they break. Well, yeah. I break it, you fix it. Martin> You'll learn about the dynamics of people management once you get out Martin> into the ugly real world. That might be soon, I hope. I am tired of being so broke and have been sending a resume around. I've an apointment in the morning with an IT recruiter. Hopefully by the end of the month I'll be employed. -- Smarter than a phoo phish am I, soon freed when be I weird. Hight karlheg, hailing from deB.ORG, am I. Freed will you be. mailto:karlheg＠debian.org (Karl M. Hegbloom)

1 participants
0 comments

Re: Not linking so many things to the lib-src stuff? 24 years, 1 month

Karl M. Hegbloom

>>>>> "Stephen" == Stephen J Turnbull <turnbull(a)sk.tsukuba.ac.jp> writes: Stephen> Here's what I get for 21.1 and 21.2 on `ldd gnuserv' and `ldd ctags' Stephen> bash-2.04$ ldd ~/Projects/XEmacs/Builds/21.2/lib-src/ctags Stephen> libdl.so.2 => /lib/libdl.so.2 (0x40021000) Stephen> [ ... ] Yes, that's what I'm talking about. They are linked to things they don't really use. Stephen> I'm using Debian woody versions of everything, as Karl probably is Yes, of course. Stephen> I don't understand why gnuserv or ctags (or movemail, which has the Stephen> same dependencies as ctags) need libm, libdl, libdb, libncurses, and Stephen> libcrypt, though. And on 21.2 they also pick up libpq, which Stephen> obviously isn't needed since it isn't in 21.1. And none of those Stephen> libraries depend on anything except libc and ld.so. I believe that's Stephen> what Karl is referring to. Again, right... That's what I was referring to. KMH> A question about `ld' now... Is there a reason why, other KMH> than "it's just not implemented" that `ld' cannot or does not KMH> remove depends on libs that are not actually used by any KMH> particular binary? Stephen> Probably nobody ever thought about it. It's not like it's a big deal Stephen> in most cases, since they are shared libraries and are required to be Stephen> present for the "main event" (firing up XEmacs itself). And that's Stephen> going to be the normal case (that the over-linked binaries are part of Stephen> a larger app that _does_ need the libraries, so they probably are Stephen> already mapped into memory, too). Yah... but the thing is that when building the Debian packages, the XEmacs binary distribution gets split into several packages. There's going to be a `support-bin' package that contains the "lib-src" stuff, a package with the undumped `*.elc' code, and another with the uncompiled `*.el' and dumped `*.elc'. And of course, there will be several `editor-binary' packages; one for `mule', another for `mule+canna+wnn', one for `vanilla', one for `minimalist', etc. (my packager setup is very configurable. I plan to support in-house or site-customized *.deb builds complete with dumped-lisp.) What I've done is to run an extra configure just for the `support-bin'; but that still links in a bunch of extra stuff... and then when the packageing tools run the `dpkg-shlibdeps' to compute a Depends line for the debian/control, it puts in `ncurses' etc. when those binaries really don't need to depend on that. I could get by just leaving it there, but I'm a perfectionist. It screws up the graph. Stephen> Ie, it's an expensive optimization that probably doesn't buy much. Stephen> It's only with the recent proliferation of special-purpose libraries, Stephen> which depend on other special-purpose libraries, that it really starts Stephen> to make sense. It turns out to not be very hard to just not link them to all that extra stuff to begin with. Perhaps that's true often enough that it's not worthwhile to implement a cure for it in `ld'? I've no way to know yet, really; I don't know what `ld' really does; I've never tried to read its sources. Perhaps I could understand it now if I tried... a year or so ago I could not have. Hmmm. When it runtime link edits, it must have to walk lists of libraries that are listed in the libs and binary as being linked... walk symbol tables and link location tables... So why can't `ld' do the similar at link time (make a tick in an assoc table for each lib as it's referrenced), and not write into the finished product list items for libs not ever referenced? Perhaps then a switch should be provided that tells it to just do what I say, not what I mean? -- Smarter than a phoo phish am I, soon freed when be I weird. Hight karlheg, hailing from deB.ORG, am I. Freed will you be. mailto:karlheg＠debian.org (Karl M. Hegbloom)

1 participants
0 comments

Re: libXau.a or libXau.so: Survey. 24 years, 1 month

Barry Wilkes

karlheg(a)bittersweet.inetarena.com (Karl M. Hegbloom) writes: > Will folks with other than Debian GNU/Linux please have a look and > see if there's a static .a or shared .so of libXau on you machines? > > The question is, do all Xlibs install that as a static lib only, or > is it sometimes a shlib? Well, I am running XFree86 4.0.1, installed from a binary tarball obtained from xfree86.org. It has only given me the static version. On my laptop, running stock redhat 6.2, there is also only the static version. Regards, Barry.

1 participants
0 comments

Re: Not linking so many things to the lib-src stuff? 24 years, 1 month

Karl M. Hegbloom

>>>>> "Martin" == Martin Buchholz <martin(a)xemacs.org> writes: Martin> In 21.2 there has been a fair amount of effort to make sure that your Martin> run-of-the-mill lib-src binary is not linked with any X stuff, and Martin> that gnuserv is linked with those X libs, and only those X libs, Martin> required for its `xauth' feature. Hmmm... Perhaps it does the "right thing" on some OS but not others? Could it be the `ld' thing I asked about? Perhaps some vendor's `ld' will not link everything you list, but only the ones actually referenced? (Unless you give it a DWIS switch, perhaps, in some ideal universe?) Martin> It seems to me that 21.2 is working exactly as designed. A quick look Martin> at 21.1 suggests that it is doing the same thing. I vaguely remember Martin> having implemented this stuff years ago. Martin> Please let me know exactly what is broken for you. I'll have to double check... Ok; just did... All of the "lib-src" binaries aside from the `gnus*' are compiled with ${ldflags} on the CC line. ${ldflags} is built using ${ld_libs_general}, which looks like: ld_libs_general=-ldl -ldb -lgpm -lncurses -L/usr/lib -lesd -laudiofile -lm -lpq -lldap -llber -lm -lutil -lgcc -lc -lgcc /usr/lib/crtn.o ... in the "lib-src/Makefile" for the XEmacs I'm typing in right now... Hmmm. `ldd' shows them *not* to be linked to all that stuff though... Ah, ok. I just looked again... in the GNUMakefile... I have that `ld_libs_general=' line sharped out, like in the patch for "lib-src/Makefile.in.in" I pasted when I asked the questions that started this thread. Prior to that, all of them, shown by `ldd' output, had been linked to everything in that ${ld_libs_general=} list. So, I conclude that we should patch it out, at least on GNU/Linux. The question remains: will it still work right on other OS then? Martin> Xauth requires Xau, which requires Xt, which requires X11, which Martin> requires ICE and SM... (maybe). Check out the dependencies using ldd Martin> (I haven't). If a shlib does *not* have a `ld' link against a library it calls a routine from, but a final binary links that called-on library itself, does everything just work, or must the shlibs be built with explicit interdependancy information specified on the link command line? How and where could I find the answer to that question and others it may bring up (ones an instructor or tutor would lead me to ask) without asking in *this* mailing list? ;-) Yous seem like the types who don't mind my questions overmuch... Hmmm... lemme think... Seems like the interdependancies probably have to be declared explicitly when the shlib is linked, so that the shlib itself can be link editted at initial mmapping time. Is that right? If so, then using `ldd' on those shlibs _will_ produce a valid answer to the question of whether `gnuserv' and `gnuclient' are linking only required libraries. 8-) Alright... what I want is libXau and anything it requires plus anything they require... Ok. The results. On my Debian GNU/Linux "Woody" machine, with XFree86-4.0.1 prerelease test packages installed, I find that only a static ("*.a") Xau is installed, and it comes from the `xlibs-dev' package... bittersweet% dpkg --status xlibs-dev Package: xlibs-dev Status: install ok installed Priority: optional Section: x11 Installed-Size: 76292 Maintainer: Branden Robinson <branden(a)debian.org> Source: xfree86 Version: 4.0.1-0phase2v12 Replaces: xbase (<< 3.3.2.3a-2), xdevel, xpm4g-dev, xmanpages, xlib6g-dev (<< 4.0), xlib6g-static Provides: libxpm4-dev, xmanpages Depends: xlibs, libc6-dev Conflicts: xdevel, xlib6g-dev (<< 4.0), xlib6g-static, xpm4g-dev, xmanpages Description: X Window System client library development files xlibs-dev provides static versions of the libraries provided in xlibs, as well as several libraries that do not exist in shared object form for various reasons (such as the fact that their API's have not stabilized). Include files and manual pages are also provided. . The libraries only available in static form include libFS, libXau, libXdmcp, libXfontcache, libXinerama, libXss, libXv, libXxf86dga, libXxf86misc, libXxf86rush, libXxf86vm, libfntstubs, liboldX, libxf86config, libxkbfile, and libxkbui. Checking on a Debian 2.2 (Potato) machine reveals that with XFree86-2.2.6, the package name is `xlib6g-dev', but the situation is the same in that there is *only* a static libXau.a provided. Using `ldd' on "libXau.a" produces "Not a dynamic executable". Linking `gnuserv' and `gnuclient' without anything specified but -lXau produces working executables. 8-) I will submit a patch and ChangeLog to the patch queue shortly. KMH> A question about `ld' now... Is there a reason why, other than "it's KMH> just not implemented" that `ld' cannot or does not remove depends on KMH> libs that are not actually used by any particular binary? Martin> Computer programmers are idiots. (Actually, that's not true. Martin> Computer programmers are selfish. Why should they invest X units of Martin> effort to save future programmers 10X of effort, especially when they Martin> have a manager breathing down their necks? This is one of the main Martin> reasons free software has a chance - we *care*.) Uh, yeah, Martin. Sure. <backs away slowly> -- Smarter than a phoo phish am I, soon freed when be I weird. Hight karlheg, hailing from deB.ORG, am I. Freed will you be. mailto:karlheg＠debian.org (Karl M. Hegbloom)

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 October 2000