XEmacs-Beta September 1998

xemacs-beta@xemacs.org

105 participants
458 discussions

Re: Portability and usage statistics (was Re: Seppuku and x_IO_error_handler() ) 25 years, 7 months

Hrvoje Niksic

SL Baur <steve(a)xemacs.org> writes: > O.K. Let's move on to SGI/Irix. Are we passed the traditional XEmacs > Fuckage or aren't we? I don't know. Darren Stalder was kindly enough > to donate access to a system to test on and ... I never heard heard > anything since from the SGI volunteer. I thought Olivier fixed problems with IRIX. > O.K. So let's try Solaris. It's the most popular commercial Unix > in the market, surely it is getting developer support? I'm working solely on Solaris. Do I count as "supporting" it? I've never bothered to make the EOS stuff work, though. > *Wrong*! We continue to get crash reports with annotations tickled > by the EOS support. There have been hundreds if not thousands of > these reports since they've been aimed at me. Is there any > developer running with Sun Solaris? Hello? You rang? > DEC OSF/1 on Alpha has had a long history of breakage with noone > working on it. As far as I know, XEmacs works on Digital Unix. At least with gcc it does. > That is my world view, and that is why I consider commercial Unix > support falling apart at the seams. I'm not buying this. Your "analysis" above is way too ad-hoc. Sorry. > If *you* don't like it, do something about it or send me equipment > and software with appropriate licenses and I can take a look at it. > Don't just complain about it. It doesn't do anyone any good. Saying that being portable is "just not as important as it used to be" doesn't help the situation either. -- Hrvoje Niksic <hniksic(a)srce.hr> | Student at FER Zagreb, Croatia --------------------------------+-------------------------------- Predestination was doomed from the start.

2 participants
1 comments

Re: Portability and usage statistics (was Re: Seppuku and x_IO_error_handler() ) 25 years, 7 months

Colin Rafferty

SL Baur writes: > Gary D Foster <Gary.Foster(a)Corp.Sun.COM> writes in xemacs-beta(a)xemacs.org: >> This talk of only supporting linux disturbs me deeply. I cannot possibly >> believe that anyone is seriously considering this? > I'm not seriously considering this. End of discussion. Except, see > below ... > O.K. Let's move on to SGI/Irix. Are we passed the traditional XEmacs > Fuckage or aren't we? I don't know. Darren Stalder was kindly enough > to donate access to a system to test on and ... I never heard heard > anything since from the SGI volunteer. Pardon me, but for the last four months or so, I've been sending SGI build reports. In that time, I have had exactly two problems, and they were both SGI's "fault". In fact, I don't think I even send in the failure reports. 1. SGI has C++ graphics libraries, and that kills the undump process. This is an easy work-around (-no-tiff). 2. The 20.4 unexelfsgi.c for SGI didn't work with the latest SGI compiler. Justin Banks (of SGI) told me to use 21.0's, and that fixed it. As far as sending you an SGI box, that would be nice, be we are just customers here, and they are a little expensive. All that I know is that as long as I am working on an IRIX box, the latest version of XEmacs will work. I can't promise more than that, but that's all I've got. -- Colin

1 participants
0 comments

Re: Portability and usage statistics (was Re: Seppuku and x_IO_error_handler() ) 25 years, 7 months

Raymond Toy

>>>>> "dv" == Didier Verna <verna(a)inf.enst.fr> writes: dv> compiler and not gcc ? How many of us don't use the GNU fileutils yet ? While I don't use GNU fileutils. I haven't had a need to. But I do use gcc, some of the binutils (but not ld: it won't make a working xemacs), sed, make. dv> I use the openwin X11 server because I have special requirements for the frame dv> buffer, I always compile with X11R6 from the X consortium, and if one day dv> XFree86 runs on my SUN a newer version than the latest free one from the dv> OpenGroup, sure I'll install and use it. At least because I can tolerate bugs I use openwin X11 server because the X11R6 doesn't support my video. While I've been using R6 for a long time, I'm slowly moving my xemacs builds to use just stock openwin. I no longer have the energy and desire that I used to in building and debugging all kinds of free software. (Kids and family and work get in the way) :-( Ray

1 participants
0 comments

func menu and latex 25 years, 7 months

Didier Verna

Steve, I remember having posted a patch to func-menu (which fixed all uses of `concat' directly with number), but it doesn't look applied to the latest packaged version. I vaguely remember it was subject to somebody else's approval isn't it ? Can we expect it to be really fixed someday ? Sorry, my xemacs-patches archive doesn't go that far in the past. --didier

1 participants
0 comments

Re: Portability and usage statistics (was Re: Seppuku and x_IO_error_handler() ) 25 years, 7 months

Didier Verna

SL Baur <steve(a)xemacs.org> writes: > Gary D Foster <Gary.Foster(a)Corp.Sun.COM> writes in xemacs-beta(a)xemacs.org: > > > This talk of only supporting linux disturbs me deeply. I cannot possibly > > believe that anyone is seriously considering this? > > I'm not seriously considering this. End of discussion. Except, see > below ... I tend to agree with Steve. Even on commercial platforms, I think that more and more people use free software. How many of us really use Sun's C compiler and not gcc ? How many of us don't use the GNU fileutils yet ? While I use the openwin X11 server because I have special requirements for the frame buffer, I always compile with X11R6 from the X consortium, and if one day XFree86 runs on my SUN a newer version than the latest free one from the OpenGroup, sure I'll install and use it. At least because I can tolerate bugs in a piece of code I use only if I'm able to track them, correct or report them, and see them fixed in a next release or patchlevel. The only reason that can make me prefer a commercial product is if I have no choice, for instance if Sun doesn't deliver enough information to make the XFree86 developpers support the Creator3D board. --didier

1 participants
0 comments

Re: Portability and usage statistics (was Re: Seppuku and x_IO_error_handler() ) 25 years, 7 months

Michael Sperber

>>>>> "sb" == SL Baur <steve(a)xemacs.org> writes: sb> We do not build on latest AIX. Not to comment on your posting in general, but we do now. I just sent patches. -- Cheers =8-} Chipsy Friede, Völkerverständigung und überhaupt blabla

1 participants
0 comments

speedbar doesn't work w/MS Windows 25 years, 7 months

Darryl Okahata

references to X11 cursors (e.g., "top_left_arrow", etc.). However, the current package contains an old version of speedbar; this problem does not exist with the latest version. -- Darryl Okahata darrylo(a)sr.hp.com DISCLAIMER: this message is the author's personal opinion and does not constitute the support, opinion, or policy of Hewlett-Packard, or of the little green men that have been following him all day.

1 participants
0 comments

native NT build problem with beta54 25 years, 7 months

John Morey

Just build b54 and only had one problem. I did a native NT build with the following defined: PACKAGEPATH="c:\\opt\\xemacs\\packages" INSTALL_DIR=c:\opt\xemacs\xemacs HAVE_MSW=1 HAVE_XPM=1 XPM_DIR=e:\development\libraries\xpm-3.4k HAVE_PNG=1 PNG_DIR=e:\development\libraries\libpng-1.0.2 ZLIB_DIR=e:\development\libraries\zlib-1.1.3 HAVE_TIFF=1 TIFF_DIR=e:\development\libraries\tiff-v3.4 HAVE_JPEG=1 JPEG_DIR=e:\development\libraries\jpeg-6b DEBUG_XEMACS=0 This link of temacs failed with the following error: link.exe ＠g:\temp\nma00414. LIBCMT.lib(tolower.obj) : error LNK2005: __tolower already defined in libc.lib(tolower.obj) LIBCMT.lib(tolower.obj) : error LNK2005: _tolower already defined in libc.lib(tolower.obj) LIBCMT.lib(osfinfo.obj) : error LNK2005: __alloc_osfhnd already defined in libc.lib(osfinfo.obj) LIBCMT.lib(osfinfo.obj) : error LNK2005: __set_osfhnd already defined in libc.lib(osfinfo.obj) LIBCMT.lib(osfinfo.obj) : error LNK2005: __free_osfhnd already defined in libc.lib(osfinfo.obj) LIBCMT.lib(osfinfo.obj) : error LNK2005: __get_osfhandle already defined in libc.lib(osfinfo.obj) LIBCMT.lib(osfinfo.obj) : error LNK2005: __open_osfhandle already defined in libc.lib(osfinfo.obj) LIBCMT.lib(dosmap.obj) : error LNK2005: __dosmaperr already defined in libc.lib(dosmap.obj) LINK : warning LNK4098: defaultlib "LIBCMT" conflicts with use of other libs; use /NODEFAULTLIB:library ..\src\temacs.exe : fatal error LNK1169: one or more multiply defined symbols found NMAKE : fatal error U1077: 'link.exe' : return code '0x491' Stop. Adding "/NODEFAULTLIB:LIBCMT" to the link line of temacs fixed the problem. Here is the patch: *** xemacs.mak.old Sun Aug 23 11:20:52 1998 --- xemacs.mak Sun Aug 23 11:21:32 1998 *************** *** 896,902 **** # !"cd $(TEMACS_SRC); cp paths.h.in paths.h" $(TEMACS): $(TEMACS_INCLUDES) $(TEMACS_OBJS) ! link.exe ＠<< $(TEMACS_LFLAGS) $(TEMACS_OBJS) $(TEMACS_LIBS) << --- 896,902 ---- # !"cd $(TEMACS_SRC); cp paths.h.in paths.h" $(TEMACS): $(TEMACS_INCLUDES) $(TEMACS_OBJS) ! link.exe /NODEFAULTLIB:LIBCMT ＠<< $(TEMACS_LFLAGS) $(TEMACS_OBJS) $(TEMACS_LIBS) << -- John Morey

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 September 1998