From: UnixOS2 Archive To: "UnixOS2 Archive" Date: Sat, 21 Dec 2002 04:44:14 EST-10EDT,10,-1,0,7200,3,-1,0,7200,3600 Subject: [UnixOS2_Archive] No. 405 ************************************************** Friday 20 December 2002 Number 405 ************************************************** Subjects for today 1 Re: Posix/2 v. EMX includes : Stefan Neis 2 Re: Autoconf and SED : Stefan Neis 3 Re: Posix/2 v. EMX includes : Stefan Neis 4 Re: Building RSYNC : Stefan Neis 5 Re: Building RSYNC : John Poltorak 6 Re: Posix/2 v. EMX includes : John Poltorak 7 Re: wxWindows & EverBlue : Adrian Gschwend" 8 Re: Make v3.80 : John Poltorak 9 [Fwd: Returned mail: see transcript for details] : Ted Sikora 10 Re: R : Thomas Hoffmann 11 Re: Make v3.80 : John Poltorak 12 Re: Posix/2 v. EMX includes : Andreas Buening 13 Re: Make v3.80 : Andreas Buening 14 ***Mail problems*** : John Poltorak 15 mail errors : Ted Sikora **= Email 1 ==========================** Date: Sat, 21 Dec 2002 00:16:35 +0100 (CET) From: Stefan Neis Subject: Re: Posix/2 v. EMX includes On Fri, 20 Dec 2002, Andreas Buening wrote: > Currently, dozens of developers are caused to add these annoying > "#ifdef __EMX__" stuff or silly preprocessor flags ever and ever again. I still think it's better if dozens of developpers need to do the same old fixes a couple of times than forcing hundreds or thousands of users to hunt for the emx.dll "of the day", where you never know how backward compatible it really will be. But I'd really have to have a hint on a time frame for libemu to form a reasonable opinion. (Holger, are you reading? ;-) ) > Currently, > emx is even not C compatible anymore and will never be again if nobody > adds new header files. Sorry? Some example? > So why not adding new entry points to the next emx release? > Why not updating a header file? I'm rather happy with the low frequency of emx releases (at least for the library level, more compiler would be great ;-) ), I wouldn't really like to have a "next emx release" in january, then another one in february (because "we" forgot something essential), then maybe yet another one in march and april (because of incompatibility issues created in the earlier ones) and then maybe a first libemu in may with a fix in august. That would be sheer horror to me. Add as many _static_ libraries simplifying developpers life, as you want (e.g. cExt.a), but please don't deliver "DLL hell"(TM) to OS/2. > How would it effect you if the emx headers contained new functions? Probably not at all - that's why I'm saying that I don't believe that it is worth the pain. > Finally, my question remains: Are there any known objections of EM > against header modifications? I don't really know. I heard some people having submitted suggestions for changes/fixes complain that it takes a long time to see anything integrated into a release (or even to see it rejected), but that's about all I know about that subject. Regards, Stefan **= Email 2 ==========================** Date: Sat, 21 Dec 2002 00:25:23 +0100 (CET) From: Stefan Neis Subject: Re: Autoconf and SED On Fri, 20 Dec 2002, John Poltorak wrote: > gcc -DHAVE_CONFIG_H -I. -I. -I.. -Zomf -O2 -s -Zmt -D__ST_MT_ERRNO__ ^^^^^ > ar cru libsed.a getopt1.obj getopt.obj regex.obj ^^ > Any clues? Remember to use the right tools depending on whether you are doing OMF builds or a.out builds! "make AR=emxomfar" should help, _if_ the Makefile(.in) doesn't used a hardcoded "ar". Regards Stefan **= Email 3 ==========================** Date: Sat, 21 Dec 2002 00:31:52 +0100 (CET) From: Stefan Neis Subject: Re: Posix/2 v. EMX includes On Thu, 19 Dec 2002, Mikus Grinbergs wrote: > I have trouble understanding this point. If there are people who > have not yet upgraded from emx-0.9c to emx-0.9d, why should these > people be more likely to install an UO2_2003 (i.e., a new direction) > instead of an emx-0.9g (perceived as a continuation of facilities) ? You got me wrong. I didn't claim that it would be easier to get people to update, I just said it's easier to keep everybody happy if there are only two or three DLL's that are widely used and required. If "every" application comes with its own flavor of emx.dll and only works with exactly _this_ DLL, things are getting difficult (in fact, they would be getting very Windows like). Regards, Stefan **= Email 4 ==========================** Date: Sat, 21 Dec 2002 00:39:26 +0100 (CET) From: Stefan Neis Subject: Re: Building RSYNC On Thu, 19 Dec 2002, John Poltorak wrote: > Could the solution be as simple as adding:- > > EXEEXT = at EXEEXT at > OBJEXT = at OBJEXT at > > to Makefile.in? If the makefile is actually using EXEEXT anywhere, than that could do. I.e. it should help if the makefiles contains stuff like rsync$(EXEEXT): various .o files (or rather $(OBJEXT) files) some rule but doesn't help at all if the Makefile is a "traditional" Unix only Makefile and just says: rsync: various .o files some rule. I rather supposed that so far no one tried to run rsync on cygwin yet, so chances are quite high that you are really faced with a "unix only" Makefile(.in)/configure.in. Regards, Stefan -- Micro$oft is not an answer. It is a question. The answer is 'no'. **= Email 5 ==========================** Date: Sat, 21 Dec 2002 11:54:49 +0000 From: John Poltorak Subject: Re: Building RSYNC On Sat, Dec 21, 2002 at 12:39:26AM +0100, Stefan Neis wrote: > On Thu, 19 Dec 2002, John Poltorak wrote: > > Could the solution be as simple as adding:- > > > > EXEEXT = at EXEEXT at > > OBJEXT = at OBJEXT at > > > > to Makefile.in? > > If the makefile is actually using EXEEXT anywhere, than that could do. > I.e. it should help if the makefiles contains stuff like > rsync$(EXEEXT): various .o files (or rather $(OBJEXT) files) > some rule > but doesn't help at all if the Makefile is a "traditional" Unix only > Makefile and just says: > rsync: various .o files > some rule. > I rather supposed that so far no one tried to run rsync on cygwin yet, > so chances are quite high that you are really faced with a "unix > only" Makefile(.in)/configure.in. Currently there is no $OBJEXT or $EXEEXT, but I don't think it would require much work to change Makefile.in, for someone who understood the way Makefile.in works. I wonder if there is any sort of guide to how to incorporate EXEEXT into Makefile.in ... > Regards, > Stefan > -- > Micro$oft is not an answer. It is a question. The answer is 'no'. > -- John **= Email 6 ==========================** Date: Sat, 21 Dec 2002 12:30:15 +0000 From: John Poltorak Subject: Re: Posix/2 v. EMX includes On Sat, Dec 21, 2002 at 12:16:35AM +0100, Stefan Neis wrote: > On Fri, 20 Dec 2002, Andreas Buening wrote: > > > Currently, dozens of developers are caused to add these annoying > > "#ifdef __EMX__" stuff or silly preprocessor flags ever and ever again. > > I still think it's better if dozens of developpers need to do the > same old fixes a couple of times than forcing hundreds or thousands of > users to hunt for the emx.dll "of the day", where you never know how > backward compatible it really will be. IMV EMX's headers are part of EM's product and other people shouldn't mess with them otherwise we will end up with huge compatibility problems, which in fact we already have in a way because the the huge variety of SHELLs, Makes etc which people use. Having said that, it seems to me that we have a ready made answer to problems as far as headers go, in the Posix/2 package. I would be interested in using those headers to see how far I can get in building various apps, but I think I would need some libs to go with them. Are there any available? > Regards, > Stefan -- John **= Email 7 ==========================** Date: Sat, 21 Dec 2002 12:50:03 +0100 (CET) From: "Adrian Gschwend" Subject: Re: wxWindows & EverBlue On Fri, 20 Dec 2002 12:08:21 +0000, 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. X is the base framework like plain PM on OS/2. Everblue tries to map X API calls to PM calls, like this all applications for X could be compiled on OS/2 (in theory), regardingless of the toolkit they use (Qt, wxWindows, GTK...). wxWindows is a cross-platform toolkit that provides a single API for all platforms, so far it's implemented on top of GTK on unix systems but as Dave wrote there seems to be an effort to do it directly on X. >I'm not sure how wxWindows fits in with X, but if X programmers used >wxWindows then would we still need EverBlue? yes because wxWindows is not that popular like for example GTK or Qt IMHO (for whatever reason). Also you couldn't run native X applications (they exist as well, especially older applications use native X instead of a windowing API). >What do X programmers normally use instead of wxWindows and how difficult >is it to convert? gtk, qt are the most popular I would say. It's absolutely futile to try to convert them to wxWindows... cu Adrian -- Adrian Gschwend at netlabs.org ktk [a t] netlabs.org ------- Free Software for OS/2 and eCS http://www.netlabs.org **= Email 8 ==========================** Date: Sat, 21 Dec 2002 14:16:49 +0000 From: John Poltorak Subject: Re: Make v3.80 On Fri, Dec 20, 2002 at 07:24:19PM +0000, John Poltorak wrote: > 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 :-(. Having installed Autoconf v2.57, I can now build Make v3.80 straight out of the box! Excellent work, Andreas, you deserve our congratulations, as I'm sure must have done much to make this possible. Maybe we could try and get this version thoroughly tested out and standardise on it. I think different versions of Make must have caused untold problems over the years, and it would be nice if could leave all old versions behind once we know this works correctly. Is there anything like a test suite for Make? -- John **= Email 9 ==========================** Date: Sat, 21 Dec 2002 15:35:30 -0500 From: Ted Sikora Subject: [Fwd: Returned mail: see transcript for details] This is a multi-part message in MIME format. --------------020500010701090104070702 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit -------- Original Message -------- Subject: Returned mail: see transcript for details Date: Sat, 21 Dec 2002 15:14:42 -0500 (EST) From: Mail Delivery Subsystem To: The original message was received at Sat, 21 Dec 2002 15:14:39 -0500 (EST) from dhcp-209-54-72-110.ct.dsl.ntplx.com [209.54.72.110] ----- The following addresses had permanent fatal errors ----- (reason: 550 ... relaying denied on 213.152.37.93) ----- Transcript of session follows ----- ... while talking to mail.manninghammills.org.: >>> RCPT To: <<< 550 ... relaying denied on 213.152.37.93 550 5.1.1 ... User unknown -- Ted Sikora tsikora at ntplx.net --------------020500010701090104070702 Content-Type: message/delivery-status; name="file:///tmp/nsmail-1.tmp" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="file:///tmp/nsmail-1.tmp" Reporting-MTA: dns; mail.ntplx.net Received-From-MTA: DNS; dhcp-209-54-72-110.ct.dsl.ntplx.com Arrival-Date: Sat, 21 Dec 2002 15:14:39 -0500 (EST) Final-Recipient: RFC822; jp at manninghammills.org Action: failed Status: 5.1.1 Remote-MTA: DNS; mail.manninghammills.org Diagnostic-Code: SMTP; 550 ... relaying denied on 213.152.37.93 Last-Attempt-Date: Sat, 21 Dec 2002 15:14:42 -0500 (EST) --------------020500010701090104070702 Content-Type: message/rfc822; name="(null).eml" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="(null).eml" Return-Path: Received: from ntplx.net (dhcp-209-54-72-110.ct.dsl.ntplx.com [209.54.72.110]) by mail.ntplx.net (8.11.6/8.11.4/NETPLEX) with ESMTP id gBLKEdl25830 for ; Sat, 21 Dec 2002 15:14:39 -0500 (EST) Message-ID: <3E04CFAB.5010300 at ntplx.net> Date: Sat, 21 Dec 2002 15:31:39 -0500 From: Ted Sikora User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: English/United States [en-US],E MIME-Version: 1.0 To: John Poltorak Subject: Re: Mail problem References: <3E036BA6.7070802 at ntplx.net> <20021220205242.S88 at eyup.org> <3E038F75.8080703 at ntplx.net> <3E039378.1060503 at ntplx.net> <20021221193858.G88 at eyup.org> <3E04CECE.709 at ntplx.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS and CyberSoft VFind Ted Sikora wrote: > Does it work? Building a computer for my sister's friend's kids for > Christmas. Windows.... arrrgghh! > > John Poltorak wrote: > >> Ted, >> >> Can you try replying to me at manninghammills.org? >> >> It appears that my DNS records have got screwed up. >> >> >> Do you know how to contact Network Solutions? It seems that my details >> have been changed to an IP address I had a long time ago. >> >> You can do it through your browser. https://www.netsol.com/en_US/manage-it/index.jhtml I know I jinxed you with all this Sendmail stuff. -- Ted Sikora tsikora at ntplx.net --------------020500010701090104070702-- **= Email 10 ==========================** Date: Sat, 21 Dec 2002 16:00:54 +0100 From: Thomas Hoffmann Subject: Re: R All, I think this is the problem I asked about here already (although without mentioning that it has to do with R): ...... Thomas Dickey wrote: >> On Wed, Oct 16, 2002 at 10:53:39PM +0100, Thomas Hoffmann wrote: >> > >>>>This is to check for an appearant error in autoconf 2.53 when >>>>trying to resolve a cascaded library search: >>>> >>>>A plain library search from a configure.ac like >>>> >>>>AC_PREREQ(2.50) >>>>AC_INIT([cascadebug], [1.0], [thoffman at zappa.sax.de]) >>>>AC_CHECK_LIB(ncurses, main) >>>>AC_OUTPUT >>>> >>>>is correctly resolved into the configure sh script. >>>> >>>>But a "cascaded" search as from this configure.ac >>>> >>>>AC_PREREQ(2.50) >>>>AC_INIT([cascadebug], [1.0], [thoffman at zappa.sax.de]) >>>>AC_PROG_CC >>>>AC_CHECK_LIB(ncurses, main, [], >>>> AC_CHECK_LIB(termcap, main, [], >>>> AC_CHECK_LIB(termlib, main))) > >> >> >> perhaps: >> >> AC_CHECK_LIB(ncurses, main, [], [ >> AC_CHECK_LIB(termcap, main, [], >> AC_CHECK_LIB(termlib, main))]) >> This was the hint I needed, but there have to be even more brackets: AC_CHECK_LIB(ncurses, main, [], [ AC_CHECK_LIB(termcap, main, [],[ AC_CHECK_LIB(termlib, main)])]) The question remains: Was the first version syntactically wrong and autoconf 2.13 just tolerated this or is ac 2.53 buggy? I remember to have read something about the eating up of brackets during macro expansion but cannot find this doc right now. Then I could decide where to report the problem: to the creators of the above code or to the autoconf maintainers. -- Maybe you can answer the questions I posed, for now I simply changed configure.ac: But why does none of the unix guys hav a problem with this? PS. The R program uses modules that are loaded during runtime. This stuff works way different under Unix and OS/2. So there will be something more to porting than a mere recompile. (And this is only one example out of many that make R rather hard to port). Thomas. Andreas Buening wrote: > 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 > **= Email 11 ==========================** Date: Sat, 21 Dec 2002 16:14:13 +0000 From: John Poltorak Subject: Re: Make v3.80 On Sat, Dec 21, 2002 at 04:52:17PM +0100, Andreas Buening wrote: > John Poltorak wrote: > > Is there anything like a test suite for Make? > > make check > > but read the comments in the README.OS2 file of the prelast > release how to do this. Do you mean this release:- ? ftp://alpha.gnu.org/pub/gnu/make/make-3.80rc2.tar.gz One problem I've come across is the same one that I found when building Autoconf, ie:- Making install in m4sugar make[2]: Entering directory `/unixos2/workdir/autoconf-2.57/lib/m4sugar' ../../tests/autom4te \ --language=m4sugar \ --freeze \ --output=m4sugar.m4f ..\..\TESTS\AUTOM4TE.[92]: /unixos2/workdir/autoconf-2.57/bin/..\..\TESTS\AUTOM4TE.: not found make[2]: *** [m4sugar.m4f] Error 127 make[2]: Leaving directory `/unixos2/workdir/autoconf-2.57/lib/m4sugar' make[1]: *** [install-recursive] Error 1 make[1]: Leaving directory `/unixos2/workdir/autoconf-2.57/lib' make: *** [install-recursive] Error 1 > 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. -- John **= Email 12 ==========================** Date: Sat, 21 Dec 2002 16:50:35 +0100 From: Andreas Buening Subject: Re: Posix/2 v. EMX includes Stefan Neis wrote: > > On Fri, 20 Dec 2002, Andreas Buening wrote: > > > Currently, dozens of developers are caused to add these annoying > > "#ifdef __EMX__" stuff or silly preprocessor flags ever and ever again. > > I still think it's better if dozens of developpers need to do the > same old fixes a couple of times than forcing hundreds or thousands of > users to hunt for the emx.dll "of the day", Even an "emx.dll of the day" would be better than what we have today. > where you never know how > backward compatible it really will be. In which way does a new function in emx 0.9x introduce a backward incompatibility to emx 0.9(x-1)? All programs that do not need this new functionality work with both versions and all programs that need this functionality work only with the new version, and if there is no new version (as it is the case now) they don't work at all. [snip] > > Currently, > > emx is even not C compatible anymore and will never be again if nobody > > adds new header files. > > Sorry? Some example? wide character support (Standard C since 1995/96), i.e. the wc*.h header files, restricted pointers. Every few years standards are extended which means new functions, new data types, new . If you say "There may never be any new function or data type or header file" then this is equivalent to "Nobody may ever use the new C Standard for programming on OS/2". With this philosophy there can be no progress, never. This means these new functions/headers/whatever MUST be incorporated into the libc. And, of course, this must be done in a compatible way. A new function/header or even a modified header does not hurt the compatibility - for all people who only use the old standard. They can still use emx 0.9(x-1) or even older versions. But a missing new function/header DOES hurt the usability for people who need the new functionality. > > So why not adding new entry points to the next emx release? > > Why not updating a header file? > > I'm rather happy with the low frequency of emx releases (at least for > the library level, more compiler would be great ;-) ), I wouldn't really > like to have a "next emx release" in january, then another one in > february (because "we" forgot something essential), then maybe yet another > one in march and april (because of incompatibility issues created in the > earlier ones) and then maybe a first libemu in may with a fix in august. > That would be sheer horror to me. Add as many _static_ libraries > simplifying developpers life, as you want (e.g. cExt.a), but please don't > deliver "DLL hell"(TM) to OS/2. The idea is that these new functions are put into emx directly as an official new release. This means new emx.dll, modified headers. There are only two alternatives: 1) Nobody may ever use the new functionality, i.e. lots of "#ifdef __EMX__", lots of failing configure's and lots of hours wasting to detect and solve the same problem ever and ever again. 2) Inofficial headers because some people don't care about your philosophy and lots of inofficial headers floating around. [snip] 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 13 ==========================** Date: Sat, 21 Dec 2002 16:52:17 +0100 From: Andreas Buening Subject: Re: Make v3.80 John Poltorak wrote: > > On Fri, Dec 20, 2002 at 07:24:19PM +0000, John Poltorak wrote: > > 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 :-(. > > Having installed Autoconf v2.57, I can now build Make v3.80 straight out > of the box! > > Excellent work, Andreas, you deserve our congratulations, as I'm sure > must have done much to make this possible. > > Maybe we could try and get this version thoroughly tested out and > standardise on it. > > I think different versions of Make must have caused untold problems over > the years, and it would be nice if could leave all old versions behind > once we know this works correctly. > > Is there anything like a test suite for Make? make check but read the comments in the README.OS2 file of the prelast release how to do this. 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 14 ==========================** Date: Sat, 21 Dec 2002 21:39:54 +0000 From: John Poltorak Subject: ***Mail problems*** It seems as though my DNS records have been messed up for some reason and routing for my domain is now going to my old ISP.... If you have sent any mail to the os2-unix list recently and it has not shown up, this may explain why. For the time being, I'm going to try and set up the address os2-unix at manninghammills.org as an alternative address and hope that can be used. I apologise for any inconvenience. -- John **= Email 15 ==========================** Date: Sat, 21 Dec 2002 23:55:32 -0500 From: Ted Sikora Subject: mail errors