From: UnixOS2 Archive To: "UnixOS2 Archive" Date: Fri, 20 Dec 2002 04:44:11 EST-10EDT,10,-1,0,7200,3,-1,0,7200,3600 Subject: [UnixOS2_Archive] No. 404 ************************************************** Thursday 19 December 2002 Number 404 ************************************************** Subjects for today 1 Re: Posix/2 v. EMX includes : Andreas Buening 2 Re: R : Andreas Buening 3 RE: wxWindows & EverBlue : Dave Webster 4 RE: wxWindows & EverBlue : Dave Webster 5 Re: wxWindows & EverBlue : Ken Ames 6 PVR : John Poltorak 7 wxWindows & EverBlue : John Poltorak 8 RE: wxWindows & EverBlue : Steve Wendt 9 RE: wxWindows & EverBlue : Steve Wendt 10 Re: TD-Soft : John Poltorak 11 Re: wxWindows & EverBlue : John Poltorak 12 Re: Mailman: update : Ted Sikora 13 Re: Mailman: update : Ted Sikora 14 PDKSH stabilised ? : John Poltorak 15 Autoconf and SED : John Poltorak 16 Re: Make v3.80 : John Poltorak 17 Re: Mailman: update : John Poltorak 18 RE: wxWindows & EverBlue : Stefan Neis **= Email 1 ==========================** Date: Fri, 20 Dec 2002 00:08:32 +0100 From: Andreas Buening Subject: Re: Posix/2 v. EMX includes Stefan Neis wrote: > > On Thu, 19 Dec 2002, Andreas Buening wrote: > > > I think it would be the _much_ better solution to _update_ the EMX > > headers. > > What do you mean by "updating"? Open string.h in your favorite editor, add the lines extern int strcasecmp(const char *, const char*); extern int strncasecmp(const char *, const char *, size_t); and save the file. Then you create a new .c file with the following content: #include int strcasecmp(const char *s1, const char*s2) { return stricmp(s1, s2); } int strncasecmp(const char *s1, const char*s2, size_t len) { return strnicmp(s1, s2, len); } Then you save also this file and exit your editor. Finally you upload everything as emx 0.9x to hobbes. That's what I call "update". > > I'm getting sick of this strcasecmp() and other trivial stuff. > > That's all only happening because EMX was modelled along the lines of > the other then existing OS/2 compilers, so it has stricmp just as any > other DOS, OS/2 or Windos compiler instead of strcasecmp and IIRC there > is even _some_ standard which claims this to be the "correct" name for > that function. This doesn't matter. A lot of systems have strcasecmp(), a lot of packages use it. It could be implemented by just two lines of code. I'm not talking about implementing link() or hacking the OS/2 kernel. > But there are more important issues than those microscopic extensions. A > nicely integrated pthreads library for example would be very helpful. Every few months this issue comes back again. Then the postings start: "I used to use #ifdef __EMX__ ...", "No, -Dstrcasecmp=stricmp is much better". So many people are permanently offended by this absolutely primitive problem. So much time is wasted for these strcasecmp discussions. If you read this posting you're wasting time for basically nothing. ;-) > > Why can't er just add a line to string.h and an entry point to > > emx*.dll and everything will be fine. > > Because it won't help. Look at how many people are still using emx-0.9c > (tough I have not the slightest idea for what reasons). Adding yet > another version of headers and DLLs is just going to make life _more_ > complicated. Most people (including me) don't upgrade their software installation as long as it's not necessary. Never touch a running system. Nobody causes them to upgrade to a newer version. If anybody still uses OS/2 2.0, fine. But if they want to see the latest xyz running on their systems they might have to upgrade to a new emx. If they want to see the latest mozilla/java/odin/whatever they might have to upgrade to another OS/2 fixpack. So what? Currently, dozens of developers are caused to add these annoying "#ifdef __EMX__" stuff or silly preprocessor flags ever and ever again. Even more people waste time to follow this discussion. Currently, emx is even not C compatible anymore and will never be again if nobody adds new header files. So why not adding new entry points to the next emx release? Why not updating a header file? > > However, for additional headers like sysexits.h I see no problem > > to add them to the libunixos2 stuff but I don't like the idea > > of having several versions of standard headers floating around. > > I've come to appreciate the flexibility that those two sets of header > files/libraries do offer: > - If I need something that works on OS/2&DOS or without DLL's or if using > something aimed at VAC++ originally, I use standard EMX. > - If I need an extended UNIX support, I add Posix/2 stuff and usually I > can live with the resulting restrictions(won't work on DOS and > requires EMX dll's). How would it effect you if the emx headers contained new functions? Finally, my question remains: Are there any known objections of EM against header modifications? Bye, Andreas -- One OS to rule them all, One OS to find them, One OS to bring them all and in the darkness bind them In the Land of Mordor where the Shadows lie. **= Email 2 ==========================** Date: Fri, 20 Dec 2002 00:19:20 +0100 From: Andreas Buening Subject: Re: R Christian Hennecke wrote: > > On Thu, 19 Dec 2002 16:20:22 +0100, Andreas Buening wrote: > > >> checking for main... (cached) no > >> checking for main in -lncurses... ./configure[11387]: syntax error: `(' > >> unexpected > > > >Which autoconf did you use? If you send me the code around > >line 11387 I _might_ be able to see what's wrong. > > The latest and greatest I could find at OS2Ports.com: 2.53b release 2 > > Here is the code starting with line 11385: > > rm -f conftest.$ac_objext conftest$ac_exeext conftest.$ac_ext > if test "$ac_cv_search_opendir" = no; then > for ac_lib in dir; do > LIBS="-l$ac_lib $ac_func_search_save_LIBS" > cat >conftest.$ac_ext <<_ACEOF > #line $LINENO "configure" > #include "confdefs.h" This seems to be the wrong piece of code. Maybe the line numbers got screwed up. This happens sometimes. Seems to depend on the shell. Did you use pdksh 5.2.14 release 2? If your configure is not too large you send it by mail (compressed, of course). Bye, Andreas -- One OS to rule them all, One OS to find them, One OS to bring them all and in the darkness bind them In the Land of Mordor where the Shadows lie. **= Email 3 ==========================** Date: Fri, 20 Dec 2002 07:46:46 -0600 From: Dave Webster Subject: RE: wxWindows & EverBlue I should probably leave this one with Stefan as he is the gtk on OS/2 expert and probably knows more about this. But one of the latest efforts by the wxWindows team has been wxX11, which unlike wxGTK and wxMotif is an effort to write the toolkit directly for X itself. It is well under way and when done, kits like EverBlue will not be needed. As for what X programmer actually use these days, I have no idea, really. -----Original Message----- From: John Poltorak [mailto:jp at eyup.org] Sent: Friday, December 20, 2002 6:08 AM To: os2-unix at eyup.org Subject: wxWindows & EverBlue Can someone explain the difference between wxWindows and the EverBlue project? As I understand it, Everblue is trying to convert Xlib to PM or somesuch. I'm not sure how wxWindows fits in with X, but if X programmers used wxWindows then would we still need EverBlue? What do X programmers normally use instead of wxWindows and how difficult is it to convert? -- John **= Email 4 ==========================** Date: Fri, 20 Dec 2002 08:28:13 -0600 From: Dave Webster Subject: RE: wxWindows & EverBlue Pretty standard situation in Open Source though. A lot of competing projects doing the same thing. It's always nice when two groups, attempting to achieve roughly the same thing can join forces. Another wx project of interest is probably wxUniv. Unlike the rest of the wx project, of which the major goal and focus is a cross platform toolkit that delivers NATIVE API widgets on all it's supported platforms, this is one that is more Java like, by have no real concern for native look and feel because it provides a common widget but the difference with Java is it allows you to apply "themes". The delivery of Windows XP really got that effort going. I personally feel it a sign of lack of focus by the wx team to do this stuff, but some may find these efforts interesting or even useful. Another new one is wxEmbedded if you are a fan of embedded systems with GUI needs. -----Original Message----- From: John Poltorak [mailto:jp at eyup.org] Sent: Friday, December 20, 2002 8:07 AM To: os2-unix at eyup.org Subject: Re: wxWindows & EverBlue On Fri, Dec 20, 2002 at 07:46:46AM -0600, Dave Webster wrote: > I should probably leave this one with Stefan as he is the gtk on OS/2 expert > and probably knows more about this. But one of the latest efforts by the > wxWindows team has been wxX11, which unlike wxGTK and wxMotif is an effort > to write the toolkit directly for X itself. It is well under way and when > done, kits like EverBlue will not be needed. That's an interesting development. I wonder if the EverBlue team are aware of this... Do you know, Adrian? Maybe the EverBlue team could get involved with wxWindows for OS/2 or wxW11 as it may well turn out that their efforts could be better employed in these other two projects. > -----Original Message----- > From: John Poltorak [mailto:jp at eyup.org] > Sent: Friday, December 20, 2002 6:08 AM > To: os2-unix at eyup.org > Subject: wxWindows & EverBlue > > > > Can someone explain the difference between wxWindows and the EverBlue > project? > > As I understand it, Everblue is trying to convert Xlib to PM or somesuch. > > I'm not sure how wxWindows fits in with X, but if X programmers used > wxWindows then would we still need EverBlue? > > What do X programmers normally use instead of wxWindows and how difficult > is it to convert? -- John **= Email 5 ==========================** Date: Fri, 20 Dec 2002 11:23:11 -0800 From: Ken Ames Subject: Re: wxWindows & EverBlue Everblue and wxWindows don't have much at all in common. wxWindows is a cross-platform windowing library and Everblue is an implementation of xlib calls being translated directly to OS/2's PM API. this would mean no need for XFree86, HOB X11, Exceed from hummingbird, or any other x server and it's libs. Ken John Poltorak wrote: >Can someone explain the difference between wxWindows and the EverBlue >project? > >As I understand it, Everblue is trying to convert Xlib to PM or somesuch. > >I'm not sure how wxWindows fits in with X, but if X programmers used >wxWindows then would we still need EverBlue? > >What do X programmers normally use instead of wxWindows and how difficult >is it to convert? > > > > **= Email 6 ==========================** Date: Fri, 20 Dec 2002 11:41:27 +0000 From: John Poltorak Subject: PVR Does anyone know if there is an Open Source project for developing a Personal Video Recorder? A couple of device drivers for supporting Win-TV cards have already been ported from Linux, so it may be relatively easy to port some Linux TV apps now... -- John **= Email 7 ==========================** Date: Fri, 20 Dec 2002 12:08:21 +0000 From: John Poltorak Subject: wxWindows & EverBlue Can someone explain the difference between wxWindows and the EverBlue project? As I understand it, Everblue is trying to convert Xlib to PM or somesuch. I'm not sure how wxWindows fits in with X, but if X programmers used wxWindows then would we still need EverBlue? What do X programmers normally use instead of wxWindows and how difficult is it to convert? -- John **= Email 8 ==========================** Date: Fri, 20 Dec 2002 13:48:57 -0800 (PST) From: Steve Wendt Subject: RE: wxWindows & EverBlue On Fri, 20 Dec 2002, Dave Webster wrote: > wxWindows team has been wxX11, which unlike wxGTK and wxMotif is an effort > to write the toolkit directly for X itself. It is well under way and when > done, kits like EverBlue will not be needed. As for what X programmer > actually use these days, I have no idea, really. This is not correct. EverBlue is similar in concept to HOB X11, i.e. you can run any X11 apps in a PM window. Thus, you would need EverBlue to run a program that uses wxX11 (or GTK+, or Qt, Xlib, or whatever). X programmers use . ;) **= Email 9 ==========================** Date: Fri, 20 Dec 2002 13:49:43 -0800 (PST) From: Steve Wendt Subject: RE: wxWindows & EverBlue On Fri, 20 Dec 2002, Dave Webster wrote: > common widget but the difference with Java is it allows you to apply > "themes". The delivery of Windows XP really got that effort going. I Swing does themes, so that's not really a valid point. **= Email 10 ==========================** Date: Fri, 20 Dec 2002 14:01:35 +0000 From: John Poltorak Subject: Re: TD-Soft On Tue, Dec 17, 2002 at 05:57:57AM -0500, Thomas E. Dickey wrote: > On Tue, 17 Dec 2002, John Poltorak wrote: > > > > > > > Should I expect to be able to build most of the apps here on OS/2:- ? > > > > ftp://invisible-island.net/ > > probably - I haven't built atac or xterm on OS/2, but Holger has built > xterm. I just tried ADD and it did build OK, but there were a couple of things I needed to do to make it go. It didn't find a couple of the ncurses headers, because they were in /usr/include/ncurses and that directory was not on the include path. For some reason I thought that if /usr/include/curses.h had the line:- #include then all the ncurses headers would be found by the particuar app. The app tried to link with curses.a (from EMX) instead of ncurses.a. Is there a way to force it to look for the correct lib? At the end I needed to run EMXBIND to convert it to an EXE. This is a perenial problem for which I have never found a satisfactory answer. I guess I need to amend the CFLAGS, but it they include -Zexe, then configure fails... BTW, ADD is a handy small curses-based calculator, if anyone wants to try it, and it's available here:- ftp://invisible-island.net/add/add.tar.gz > -- > T.E.Dickey > http://invisible-island.net > ftp://invisible-island.net > -- John **= Email 11 ==========================** Date: Fri, 20 Dec 2002 14:07:01 +0000 From: John Poltorak Subject: Re: wxWindows & EverBlue On Fri, Dec 20, 2002 at 07:46:46AM -0600, Dave Webster wrote: > I should probably leave this one with Stefan as he is the gtk on OS/2 expert > and probably knows more about this. But one of the latest efforts by the > wxWindows team has been wxX11, which unlike wxGTK and wxMotif is an effort > to write the toolkit directly for X itself. It is well under way and when > done, kits like EverBlue will not be needed. That's an interesting development. I wonder if the EverBlue team are aware of this... Do you know, Adrian? Maybe the EverBlue team could get involved with wxWindows for OS/2 or wxW11 as it may well turn out that their efforts could be better employed in these other two projects. > -----Original Message----- > From: John Poltorak [mailto:jp at eyup.org] > Sent: Friday, December 20, 2002 6:08 AM > To: os2-unix at eyup.org > Subject: wxWindows & EverBlue > > > > Can someone explain the difference between wxWindows and the EverBlue > project? > > As I understand it, Everblue is trying to convert Xlib to PM or somesuch. > > I'm not sure how wxWindows fits in with X, but if X programmers used > wxWindows then would we still need EverBlue? > > What do X programmers normally use instead of wxWindows and how difficult > is it to convert? -- John **= Email 12 ==========================** Date: Fri, 20 Dec 2002 15:51:11 -0500 From: Ted Sikora Subject: Re: Mailman: update Andrew MacIntyre wrote: > On Wed, 18 Dec 2002, Ted Sikora wrote: > > > > > The attached patch to Mailman/MailList.py represents the only difference > between the Python files in my test build and the build you zipped up. I > notice that the CGI and mail wrapper binaries in your build don't have > the .EXE extension though they are valid executables. I'm not sure > whether your choice of shell affects whether this matters or not. Im using bash. Do you think sh would be a better choice? I really haven't seen any problems but then it isn't fully functional yet. Could be a contributing factor. The /usr/bin/env python header was giving us some trouble early on. -- Ted Sikora tsikora at ntplx.net **= Email 13 ==========================** Date: Fri, 20 Dec 2002 15:52:03 -0500 From: Ted Sikora Subject: Re: Mailman: update Andrew MacIntyre wrote: > On Wed, 18 Dec 2002, Ted Sikora wrote: > > >>It fails when trying to send a mail notification to the list owner after >>making it. > > > Not quite... at least it was heading in that direction but hadn't actually > gotten to that point. > > The attached patch to Mailman/MailList.py represents the only difference > between the Python files in my test build and the build you zipped up. I > notice that the CGI and mail wrapper binaries in your build don't have > the .EXE extension though they are valid executables. I'm not sure > whether your choice of shell affects whether this matters or not. I did that mostly for aesthetics. I wanted everything to resemble the Unix port as much as possible. All I did was remove the .exe after running emxbind on them. I configured it without the --with-cgi-ext= option. I checked it both ways it made no difference. > > The default setup assumes you have an SMTP server daemon running on > localhost. If you want to point Mailman to an alternate SMTP server, add > the following line to Mailman/mm_cfg.py: > > SMTPHOST = 'somehost.domain.com' Hmmm I think my sendmail setup will not recognize localhost. > > after the > > ARCHIVE_TO_MBOX = -1 > > line (appropriately adjusting the FQDN of course). > > BTW, if we get to the point of a workable package, I would like to change > the name of emx_link.py to emx_unix.py, so that I can add further > Unix/Posix emulation routines to it, rather than separate files. If/when > you get to that point, let me know and I'll send you the necessary > updates. > , fname) > > def Save(self): So I don't need that last patch, Mailman_Utils.py.patch.v2? I'll try it tonight. -- Ted Sikora tsikora at ntplx.net **= Email 14 ==========================** Date: Fri, 20 Dec 2002 16:28:38 +0000 From: John Poltorak Subject: PDKSH stabilised ? Looking at what appears to be the Homepage for PDKSH:- http://web.cs.mun.ca/~michael/pdksh there has been no work done on it since July 1999. Does this mean, as IBM would say, that PDKSH has stabilised? Or does PDKSH have a different Homepage? -- John **= Email 15 ==========================** Date: Fri, 20 Dec 2002 16:40:25 +0000 From: John Poltorak Subject: Autoconf and SED With the continuing enhancement of Autoconf, I can't tell whether instructions for building SED, which worked previously, are still applicable. Currently, when building SED v3.02, I am running these scripts before configure:- aclocal automake autoconf autoheader I'm using the most recent OS/2 releases of Autoconf and Automake, but I get these errors:- gcc -DHAVE_CONFIG_H -I. -I. -I.. -Zomf -O2 -s -Zmt -D__ST_MT_ERRNO__ -c `test -f 'regex.c' || echo './'`regex.c rm -f libsed.a ar cru libsed.a getopt1.obj getopt.obj regex.obj echo libsed.a libsed.a make[2]: Entering directory `U:/unixos2/workdir/sed-3.02/lib' make[2]: Nothing to be done for `install-exec-am'. make[2]: Nothing to be done for `install-data-am'. make[2]: Leaving directory `U:/unixos2/workdir/sed-3.02/lib' make[1]: Leaving directory `U:/unixos2/workdir/sed-3.02/lib' Making install in sed make[1]: Entering directory `U:/unixos2/workdir/sed-3.02/sed' source='sed.c' object='sed.obj' libtool=no \ depfile='.deps/sed.Po' tmpdepfile='.deps/sed.TPo' \ depmode=gcc u:/bin/sh ../depcomp \ gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../lib -Zomf -O2 -s -Zmt -D__ST_MT_ERRNO__ -c `test -f 'sed.c' || echo './'`sed.c source='compile.c' object='compile.obj' libtool=no \ depfile='.deps/compile.Po' tmpdepfile='.deps/compile.TPo' \ depmode=gcc u:/bin/sh ../depcomp \ gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../lib -Zomf -O2 -s -Zmt -D__ST_MT_ERRNO__ -c `test -f 'compile.c' || echo './'`compile.c source='execute.c' object='execute.obj' libtool=no \ depfile='.deps/execute.Po' tmpdepfile='.deps/execute.TPo' \ depmode=gcc u:/bin/sh ../depcomp \ gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../lib -Zomf -O2 -s -Zmt -D__ST_MT_ERRNO__ -c `test -f 'execute.c' || echo './'`execute.c source='utils.c' object='utils.obj' libtool=no \ depfile='.deps/utils.Po' tmpdepfile='.deps/utils.TPo' \ depmode=gcc u:/bin/sh ../depcomp \ gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../lib -Zomf -O2 -s -Zmt -D__ST_MT_ERRNO__ -c `test -f 'utils.c' || echo './'`utils.c gcc -Zomf -O2 -s -Zmt -D__ST_MT_ERRNO__ -Zcrtdll -Zlinker /exepack:2 -Zlinker /pm:vio -o sed.exe sed.obj compile.obj execute.obj utils.obj ../lib/libsed.a LINK386 : fatal error L1104: ..\lib\libsed.a : not valid library make[1]: *** [sed.exe] Error 1 make[1]: Leaving directory `U:/unixos2/workdir/sed-3.02/sed' make: *** [install-recursive] Error 1 Any clues? -- John **= Email 16 ==========================** Date: Fri, 20 Dec 2002 19:24:19 +0000 From: John Poltorak Subject: Re: Make v3.80 On Sun, Dec 08, 2002 at 05:14:30PM +0000, John Poltorak wrote: > > > Has anyone tried building Make v3.80:- ? > > > ftp://ftp.gnu.org/pub/gnu/make/make-3.80.tar.gz I was about to try and then I noticed it requires Autoconf v2.54... just as I was hoping to get a stable environment using v2.53 :-(. > I just noticed that a recent version of Make on Hobbes:- > > > http://hobbes.nmsu.edu/pub/os2/dev/util/make-3_79_2a1-bin.zip > > > was built straight from the CVS source without any patches. It looks as > though Andreas Buening may have got all his fixes included in the > mainstream version so we may finally stop having to do catch up with GNU > Make... This builds fine on my system, but I still have a problem with it while building Autoconf... -- John **= Email 17 ==========================** Date: Fri, 20 Dec 2002 20:57:01 +0000 From: John Poltorak Subject: Re: Mailman: update On Fri, Dec 20, 2002 at 03:52:03PM -0500, Ted Sikora wrote: > > The default setup assumes you have an SMTP server daemon running on > > localhost. If you want to point Mailman to an alternate SMTP server, add > > the following line to Mailman/mm_cfg.py: > > > > SMTPHOST = 'somehost.domain.com' > > Hmmm I think my sendmail setup will not recognize localhost. Maybe at localhost to the Cw macro.... > -- > Ted Sikora > tsikora at ntplx.net -- John **= Email 18 ==========================** Date: Fri, 20 Dec 2002 23:58:41 +0100 (CET) From: Stefan Neis Subject: RE: wxWindows & EverBlue On Fri, 20 Dec 2002, Steve Wendt wrote: > > wxWindows team has been wxX11, which unlike wxGTK and wxMotif is an effort > > to write the toolkit directly for X itself. It is well under way and when > > done, kits like EverBlue will not be needed. As for what X programmer > > actually use these days, I have no idea, really. > > This is not correct. EverBlue is similar in concept to HOB X11, i.e. you > can run any X11 apps in a PM window. Thus, you would need EverBlue to run > a program that uses wxX11 (or GTK+, or Qt, Xlib, or whatever). X > programmers use . ;) Unfortunately, that's the exact truth. Of course it would be great if we could convince all those linux people to use wxGTK instead of GTK+, wxMotif instead of Motif/Lesstif and wxX11 instead of Xlib and rewrite all the existing interesting software accordingly, as we then could just as easily compile a wxPM version as a wxMSW or wxMac version (or one for a different X based toolkit if you happen to have a strong preference for GTK+ and don't like Motif or vice versa) of the program, but that simply won't happen. :-( I suppose the number of X toolkits has to increase first by a factor of 3 or 4 to make people realize that the approach of "I like my favourite toolkit best, all people should use that, so I write programs only for this one toolkit" doesn't really work. Anyway, in the Unix world, _any_ GUI toolkit ultimately boils down to a wrapper around Xlib, so if you "port" Xlib to PM (what Everblue is doing) that gives you all the toolkit at once. The drawback is, that whatever you run via Everblue won't quite have a PM like look and feel, but rather feel like a GTK+ app or like a Qt app or like a Motif app... So, wxWindows is much more restricted in scope (it only tries to make wxWindows based apps run on your computer, not apps based on _any_ toolkit) but it gives you a standard PM application with the "standard" look&feel instead of an X based application with a somewhat strange look and feel. Given the choice, I'd prefer a wxWindows application, but Everblue is great/will be great for all the non-wxWindows Unix applications, just as Odin is great/will be great for all the non-wxWindows Windows applications. Regards, Stefan