January 1999 - XEmacs-Beta - XEmacs Mailing List Archives

Re: v21 under HPUX -- gcc flags to be noted or standardized? 25 years, 4 months

SL Baur

Karl Kleinpaste <karl(a)justresearch.com> writes in xemacs-beta(a)xemacs.org: > Darryl Okahata <darrylo(a)sr.hp.com> writes: >> OK, I've just compiled Pyrenean using an old gcc 2.8.1, and it >> seems to work fine. > Interesting. It might be useful to know why your build worked so > readily, whereas I've had maybe a dozen failures in the last couple > days when trying variations on "-g -O3 -Wall -Wno-switch", as auto- > selected (usually, and certainly initially) by configure. Also, why > the 20.4 builder (Marcus Thiessel <thiessel(a)rhrk.uni-kl.de>) chose the > long, involved set of options I've subsequently used with success. > If it matters, the machine in question has gcc 2.7.2, with "uname -a" > showing "HP-UX clyde A.09.07 A 9000/735 2010262023 two-user license". > Strictly a gcc age issue, perhaps? Perhaps. I did a mildly recent build of XEmacs 21 on HP/UX 10.20 a few months ago with gcc-2.8.1 (from gcc binaries that are available off the 'net somewhere) and it went without a hitch. I used the configure options: ./configure --debug=no --error-checking=none --with-gcc \ --with-scrollbars=lucid --with-menubars=lucid \ --with-dialogs=motif '--cflags=-g -fno-caller-saves -O3' --with-pop

1 participants
0 comments

question about paragraph in INSTALL file 25 years, 4 months

Richard Coleman

In the INSTALL file for 21.2.8, there is the following paragraph. The `--dynamic' option specifies that configure should try to link emacs dynamically rather than statically. The word emacs should be changed to XEmacs. Also, it would be helpful if this paragraph stated under which circumstances this option is on by default. I've noticed that on FreeBSD, most of the libraries seemed to be linked dynamically even if this flag is not given. This seems odd, since the wording in this file concerning --site-runtime-libraries seems to discourage dynamic linking of libraries. -- Richard Coleman coleman(a)math.gatech.edu

5 participants
9 comments

Re: Is there no more need of our xemacs-beta mirror? 25 years, 4 months

Didier Verna

M Schmidt writes: M> What I would like to know is: If there is no more need of it or almost none M> then feel free to send me any message whether I may kick off our M> xemacs-beta mirror. Perhaps a cvs mirror would be more usefull now (though I have no idea how this can be done). As I did with your ftp mirror, I would be the one to use it. -- / / _ _ Didier Verna http://www.inf.enst.fr/~verna/ - / / - / / /_/ / E.N.S.T. INF C201.1 mailto:verna＠inf.enst.fr /_/ / /_/ / /__ / 46 rue Barrault Tel. (33) 01 45 81 73 46 75634 Paris cedex 13 Fax. (33) 01 45 81 31 19

2 participants
1 comments

v21 under HPUX -- gcc flags to be noted or standardized? 25 years, 4 months

Karl Kleinpaste

HPUX sucks large hoovers. I already knew that, of course, but I had to spend a day and a half, on and off, trying to convince both 21.0.62 and 21.2-b8 to build. (Da Boss wants to convert to Gnus for mail. He wants to run as much as possible in an environment identical to mine.) Lots of entertaining-though-depressing failure modes presented themselves, no two of 'em alike, a few of which I've saved under http://www.cs.cmu.edu/~karl/xemacs-21/ As I was giving up and installing the 20.4 binary kit, I looked over its README and found that the "configure" line used by that contributor was quite complex. In a fit of dementia, I tried the same --cflags setting for 21.2-b8 and found that it worked. Compiled without Motif, it continues to work great. The set of flags used was: -pipe -mpa-risc-1-1 -mschedule=7100 -mjump-in-delay -funroll-loops -O5 -static Could this get into at least the PROBLEMS file, and possibly into configure, so that similar pain need not be endured by others? PROBLEMS made reference to needing -O2, which is why a couple of my attempts used it, but that didn't help at all. BTW, using HPUX' own cc was an even bigger waste of time than most efforts.

3 participants
2 comments

Re: 21.0.62: Can't get pui to work 25 years, 4 months

Holger Schauer

>>>>"JV" == Jan Vroonhof schrieb am 07 Jan 1999 20:26:15 +0100: JV> The best solution is to go load JV> ftp.xemacs.org:/pub/xemacs/pgp-keys/martin_buchholz.asc and type JV> M-x mc-snarf This does the trick, thanks Jan. >> I remember having heard about a variable to stop using PGP. So, >> where it is or what else am I supposed to do (besides fetching the >> signatures)? JV> package-get-require-signed-base-updates This should be mentioned in the Help (i.e. the Info) File, at least. It could be also be a button in the current menu. What else to say: man, I'm _really_ impressed. Holger -- --- http://www.coling.uni-freiburg.de/~schauer/ --- "Warum kostet Linux nichts? Warum gibt es kein einheitliches Frontend?" -- Aus "Wie starte ich einen Endlosthread ?", Teil 1327

2 participants
1 comments

Re: REMINDER: Don't dynamically link distributed executables (was Re: question about paragraph in INSTALL file) 25 years, 4 months

Jan Vroonhof

Rick Campbell <rick(a)campbellcentral.org> writes: > If you're distributing an executable over the net, it should be > statically linked, period. Disk and memory are cheap, throwing out > program integrity to save disk and memory makes no sense. However you forget that with modern libc it is close to impossible to static link. c.f. Solaris. Jan

5 participants
6 comments

Re: set-text-properties question 25 years, 4 months

Hrvoje Niksic

Colin Rafferty <craffert(a)ms.com> writes: > My basic problem is that I am copying strings from a buffer and > writing them out. Why don't you use `buffer-substring-no-properties', then? It seems most suited for this operation.

1 participants
0 comments

Re: v21 under HPUX -- gcc flags to be noted or standardized? 25 years, 4 months

Karl Kleinpaste

Darryl Okahata <darrylo(a)sr.hp.com> writes: > This was with HP's cc (the *unbundled* one) ... > [ Note: I had to hand-edit the Makefiles to use profile-based optimization ... >> BTW, using HPUX' own cc was an even bigger waste of time than most efforts. > Only if it's the bundled one good only for kernel building. I don't think it's reasonable to suggest that building XEmacs be made dependent on (or even suggest the use of) a compiler that is neither gcc nor HPUX' own typically-bundled kernel, especially if there are circumstances which require further hand-editing of makefiles in order to make everything fly. I imagine that "most" folks building XEmacs will have gcc; anyone who wants it can have it. A set of documented options which is sure to build a working XEmacs in that environment ought to be provided.

2 participants
1 comments

Re: The default value is the issue (was XEmacs 21 /vs./ my keyboard: I want my DEL back) 25 years, 4 months

Gary D. Foster

>>>>> "sb" == SL Baur <steve(a)xemacs.org> writes: sb> Count me on the side believing the default delete direction sb> change as being a terrible thing. We already have a sb> well-defined delete forward key. It is C-d. It requires less sb> hand motion than the function key and has been in place sb> forever. Personally, I disagree... We have a long history of changing defaults to a setting that causes bugs to be flushed out and made visible. Setting d-k-d-f to 't will most definitely cause a large increase in visibility and help to flush out any remaining bugs in the tty handling code as well as any modes that may have gotten missed in the sweeps. sb> Maybe what we need are styles like CC mode uses. It wouldn't sb> be all that difficult to implement and if getting sensible sb> behavior required (setq xemacs-interface-style 'emacs) in sb> .emacs I could live with that. That would be extremely cool. Perhaps it could tie into some type of color-scheme setting as well... a style could include a color-scheme as well as an interface style. Make a bunch of different areas settable via styles and then lump all of those into one meta-style. Maybe I'm just rambling, though... -- Gary F. -- "There may not be a place for humans in the future... if we're successful." -- Rodney Brooks, Roboticist

1 participants
0 comments

Re: set-text-properties question 25 years, 4 months

Colin Rafferty

Hrvoje Niksic writes: > Colin Rafferty <craffert(a)ms.com> writes: >> Could someone please explain to me why `set-text-properties' is >> ideologically blasphemous. > Because it removes *all* the properties, not only those that your > application has set up. This can be catastrophic for hooks that > depend on properties being preserved. > It is a much better coding practice to remove the properties you > consider harmful (e.g. `read-only' or `keymap') using > `remove-text-properties'. >> Specifically, I want to get rid of all text properties on a string, >> and I don't see why it is really such a big deal. > It may not be all that blasphemous for strings that you copy out of a > buffer. Still, it's best avoided, unless you're sure you need it. Thanks for the explanation. My basic problem is that I am copying strings from a buffer and writing them out. In some versions of emacs, this write text-property crap into the output file. Since I know what I want, and it is my code's file that I am removing the properties from, I feel justified in using `set-text-properties'. Again, thanks. -- Colin

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