From: UnixOS2 Archive To: "UnixOS2 Archive" Date: Wed, 18 Dec 2002 04:44:02 EST-10EDT,10,-1,0,7200,3,-1,0,7200,3600 Subject: [UnixOS2_Archive] No. 402 ************************************************** Tuesday 17 December 2002 Number 402 ************************************************** Subjects for today 1 Re: Building RSYNC : Ken Ames 2 Re: Building RSYNC : Yuri Dario" 3 Re: Building RSYNC : Ken Ames 4 Re: Building RSYNC : Ken Ames 5 Re: Building RSYNC : John Poltorak 6 Re: Building RSYNC : John Poltorak 7 Re: Terminal choices : John Poltorak 8 Building Patch : John Poltorak 9 Re: Building RSYNC : Ken Ames 10 Re: Building RSYNC : John Poltorak 11 Re: Building RSYNC : Stefan Neis 12 Re: Building RSYNC : John Poltorak 13 PRIMA : John Poltorak 14 Re: Building RSYNC : Yuri Dario" 15 Re: Building RSYNC : Stefan Neis 16 EMX.DLL required? : John Poltorak 17 Re: Mailman: update : Ted Sikora 18 Re: Building RSYNC : John Poltorak 19 Re: Building RSYNC : John Poltorak 20 Re: Terminal choices : Thomas Dickey 21 Re: Ncurses ticdir : Thomas Dickey 22 Posix/2 v. EMX includes : John Poltorak 23 Re: EMX.DLL required? : Illya Vaes 24 Re: EMX.DLL required? : John Poltorak 25 Re: Posix/2 v. EMX includes : Stefan Neis 26 Re: Building RSYNC : Stefan Neis 27 Re: Mailman: update : Andrew MacIntyre 28 Re: R : Thomas Hoffmann **= Email 1 ==========================** Date: Wed, 18 Dec 2002 01:56:05 -0800 From: Ken Ames Subject: Re: Building RSYNC hi, I added the following to the end of my string.h file since it seemed the correct place for a string function - #if !defined(strcasecmp) #define strcasecmp stricmp #endif #if !defined(strncasecmp) #define strncasecmp strnicmp #endif haven't had any troubles with that, hth. Ken Yuri Dario wrote: >Hi John, > > > >>>strcasecmp should be translated to stricmp (that should already in >>>my patch). >>> >>> >>Patching appeared to work successfully. >> >> > >I see that I added > >#ifdef __EMX__ >#define strncasecmp strnicmp >#define strcasecmp stricmp >#endif > >at the end of config.h >Since I forgot to add the same lines to config.h.in, configure didn't create the proper header file. > > >Bye, > > Yuri Dario > >/* > * member of TeamOS/2 - Italy > * http://www.quasarbbs.net/yuri > * http://www.teamos2.it > * http://www.opera.com/os2/ > */ > > > > **= Email 2 ==========================** Date: Wed, 18 Dec 2002 08:41:34 +0100 (CET) From: "Yuri Dario" Subject: Re: Building RSYNC Hi John, >> strcasecmp should be translated to stricmp (that should already in >> my patch). >Patching appeared to work successfully. I see that I added #ifdef __EMX__ #define strncasecmp strnicmp #define strcasecmp stricmp #endif at the end of config.h Since I forgot to add the same lines to config.h.in, configure didn't create the proper header file. Bye, Yuri Dario /* * member of TeamOS/2 - Italy * http://www.quasarbbs.net/yuri * http://www.teamos2.it * http://www.opera.com/os2/ */ **= Email 3 ==========================** Date: Wed, 18 Dec 2002 09:08:04 -0800 From: Ken Ames Subject: Re: Building RSYNC hi John, sure it is, a global solution to a global problem and it is a string function so it belongs in string.h and anyone competent enough to build a package can surely edit a file.an updated string.h could be placed on unixos2 page and made available this way also. just something EM missed I am sure but nobody is perfect. Ken John Poltorak wrote: >On Wed, Dec 18, 2002 at 01:56:05AM -0800, Ken Ames wrote: > > >>hi, >> I added the following to the end of my string.h file since it seemed >>the correct place for a string function - >> >>#if !defined(strcasecmp) >>#define strcasecmp stricmp >>#endif >>#if !defined(strncasecmp) >>#define strncasecmp strnicmp >>#endif >> >>haven't had any troubles with that, hth. >> >> > >It may well work, but I don't think it is the correct way of addressing >the problem. > >Have you managed to build RSYNC? > >I still can't get rid of some errors related to SYSLOG... > > > > >>Ken >> >> > > > > **= Email 4 ==========================** Date: Wed, 18 Dec 2002 09:24:10 -0800 From: Ken Ames Subject: Re: Building RSYNC hi John, > >Now that I've managed to build RSYNC.EXE, I'm aware of three problems >which needed to be overcome, ie missing strcasecmp, missing library, and >conversion to .EXE. > >The first can be overcome by adding -Dstrcasecmp=stricmp to CFLAGS and the >second by setting %LIBS% to '-lsyslog -lsocket', but I can't come up with >the correct FLAGS for creating an EXE, although I've tried a number of >things... Setting LDFLAGS='-Zexe causes configure to fail. > > this is not a good solution. the strcasecmp problem comes up regularly while porting. a replacement string.h with needed repair should be provided on unixos2 site or hobbes. >I thought Autoconf might have worked out which *FLAGS were correct in an >OS/2 environment... > > > Ken **= Email 5 ==========================** Date: Wed, 18 Dec 2002 10:26:28 +0000 From: John Poltorak Subject: Re: Building RSYNC On Wed, Dec 18, 2002 at 08:41:34AM +0100, Yuri Dario wrote: > Hi John, > > >> strcasecmp should be translated to stricmp (that should already in > >> my patch). > >Patching appeared to work successfully. > > I see that I added > > #ifdef __EMX__ > #define strncasecmp strnicmp > #define strcasecmp stricmp > #endif > > at the end of config.h > Since I forgot to add the same lines to config.h.in, configure didn't create the proper header file. The problem with strcasecmp seems to constantly recur when building apps on OS/2. I got round it yesterday by adding:- -Dstrncasecmp=strnicmp -Dstrcasecmp=stricmp to CFLAGS. However, what we really need is a global solution, maybe by means of adding something to CONFIG.SITE. Although, there may be other solutions... Is the problem solved by using a newer version of one of autoconf/gcc/make ? As far as building RSYNC goes, I still haven't managed to resolve these errors relating to syslog:- gcc -I. -I. -Dstrncasecmp=strnicmp -Dstrcasecmp=stricmp -DHAVE_CONFIG_H -Wall -W -I./popt -c popt/poptparse.c -o popt/poptparse.o popt/poptparse.c: In function `poptParseArgvString': popt/poptparse.c:65: warning: subscript has type `char' Please ignore warnings below about mktemp -- it is used in a safe way gcc -Dstrncasecmp=strnicmp -Dstrcasecmp=stricmp -DHAVE_CONFIG_H -Wall -W -I./popt -o rsync rsync.o generator.o receiver.o cleanup.o sender.o exclude.o util.o main.o checksum.o match.o syscall.o log.o backup.o options.o flist.o io.o compat.o hlink.o token.o uidlist.o socket.o fileio.o batch.o clientname.o params.o loadparm.o clientserver.o access.o connection.o authenticate.o lib/fnmatch.o lib/compat.o lib/snprintf.o lib/mdfour.o lib/permstring.o lib/inet_ntop.o lib/inet_pton.o lib/getaddrinfo.o lib/getnameinfo.o zlib/deflate.o zlib/infblock.o zlib/infcodes.o zlib/inffast.o zlib/inflate.o zlib/inftrees.o zlib/infutil.o zlib/trees.o zlib/zutil.o zlib/adler32.o popt/findme.o popt/popt.o popt/poptconfig.o popt/popthelp.o popt/poptparse.o -lsocket log.o: Undefined symbol _syslog referenced from text segment log.o: Undefined symbol _openlog referenced from text segment make: *** [rsync] Error 1 Please ignore warnings below about mktemp -- it is used in a safe way gcc -Dstrncasecmp=strnicmp -Dstrcasecmp=stricmp -DHAVE_CONFIG_H -Wall -W -I./popt -o rsync rsync.o generator.o receiver.o cleanup.o sender.o exclude.o util.o main.o checksum.o match.o syscall.o log.o backup.o options.o flist.o io.o compat.o hlink.o token.o uidlist.o socket.o fileio.o batch.o clientname.o params.o loadparm.o clientserver.o access.o connection.o authenticate.o lib/fnmatch.o lib/compat.o lib/snprintf.o lib/mdfour.o lib/permstring.o lib/inet_ntop.o lib/inet_pton.o lib/getaddrinfo.o lib/getnameinfo.o zlib/deflate.o zlib/infblock.o zlib/infcodes.o zlib/inffast.o zlib/inflate.o zlib/inftrees.o zlib/infutil.o zlib/trees.o zlib/zutil.o zlib/adler32.o popt/findme.o popt/popt.o popt/poptconfig.o popt/popthelp.o popt/poptparse.o -lsocket log.o: Undefined symbol _syslog referenced from text segment log.o: Undefined symbol _openlog referenced from text segment make: *** [rsync] Error 1 Is there a particular syslog which I need? Or maybe I have a FLAG or LIB variable missing... This is what emxexp syslog.a shows:- ; From \usr\lib\syslog.a(syslog.o) "syslog" "vsyslog" "openlog" "closelog" "setlogmask" I can't figure out what is wrong here. > Bye, > > Yuri Dario > > /* > * member of TeamOS/2 - Italy > * http://www.quasarbbs.net/yuri > * http://www.teamos2.it > * http://www.opera.com/os2/ > */ -- John **= Email 6 ==========================** Date: Wed, 18 Dec 2002 10:31:20 +0000 From: John Poltorak Subject: Re: Building RSYNC On Wed, Dec 18, 2002 at 01:56:05AM -0800, Ken Ames wrote: > hi, > I added the following to the end of my string.h file since it seemed > the correct place for a string function - > > #if !defined(strcasecmp) > #define strcasecmp stricmp > #endif > #if !defined(strncasecmp) > #define strncasecmp strnicmp > #endif > > haven't had any troubles with that, hth. It may well work, but I don't think it is the correct way of addressing the problem. Have you managed to build RSYNC? I still can't get rid of some errors related to SYSLOG... > Ken -- John **= Email 7 ==========================** Date: Wed, 18 Dec 2002 11:20:43 +0000 From: John Poltorak Subject: Re: Terminal choices On Tue, Dec 17, 2002 at 10:36:59PM -0600, ERACC Lists wrote: > In: <20021217191935.B88 at eyup.org> > On: Tue, 17 Dec 2002 19:19:35 +0000 > Screaming: Terminal choices > John Poltorak did rant: > > +When building LESS (v378) there is a choice of terminal libraries to use > +which include xcurses, ncurses, termcap and termlib. > > +Not being familiar with these things, I don't know what the pros and cons > + are of each of them and I don't know if we ought to have a standard as > +far as UnixOS/2 goes. > > +Does anyone have a view on the matter? > > The termcap file is an old "standard" that is replaced by the > terminfo database IIRC. At least my Unixware box uses terminfo with > termcap left on the system for backward compatibility. As for > xcurses, ncurses and termlib I've rarely had chance to look at them > so can't comment on whether or not they should be considered on OS/2. > My gut feeling is if it is supported on the Linux platform we are > emulating (slackware?) then it should be supported on UnixOS/2 to > give the widest range of software support. Yes, I agree we should provide the widest range of support, except I'm not entirely sure what that means in practical terms. EMX comes with curses, termcap and btermcap libs, which I'm sure need updating or replacing. NCURSES provides the terminfo database, ncurses.a and a number of libs, none of which I'm familiar with. What other libraries are available? I'm still not sure what termlib is, whether I should have one and if so where I would get it from... > Gene > -- > +=========================-=>Unix & OS/2<=-=========================+ > # Owner and C.E.O. - ERA Computer Consulting - Jackson, TN USA # > # eCS,OS/2,UnixWare,OpenServer & Linux Business Computing Solutions # > # Please visit our www pages at http://eracc.hypermart.net/ # > +===================================================================+ > We run IBM OS/2 v.4.00, Revision 9.036 > Sysinfo: 40 Processes, 170 Threads, uptime is 27d 22h 29m 45s 336ms -- John **= Email 8 ==========================** Date: Wed, 18 Dec 2002 11:45:33 +0000 From: John Poltorak Subject: Building Patch When attempting to build GNU Patch v2.5.4, configure falls over with an error msg about the C compiler being unable to create executables and autoconf is unable to recreate a new configure script for some reason. Do I need to run aclocal, automake or somesuch first? -- John **= Email 9 ==========================** Date: Wed, 18 Dec 2002 12:44:14 -0800 From: Ken Ames Subject: Re: Building RSYNC hi John, John Poltorak wrote: >Looking at strings.h in Posix/2 the missing function is defined. > oh how I hate posix! the most unstable thing I have ever seen short of Windows itself. > >IMV the correct way forwarbid is to replace the EMX headers with the >Posix/2 >headers, but that seems like a non-trivial task. > not something I would do. that would create more problems then it solves. > >I don't like the idea of arbitrarily hacking headers since it is likely to >introduce further discrepancies into what is already a minefield of >different versions of apps which everyone seems to use. > IMV it is not a hack but more of an oversight or something EM himself just missed. Ken **= Email 10 ==========================** Date: Wed, 18 Dec 2002 13:19:51 +0000 From: John Poltorak Subject: Re: Building RSYNC On Wed, Dec 18, 2002 at 01:53:11PM +0100, Stefan Neis wrote: > On Wed, 18 Dec 2002, John Poltorak wrote: > > > log.o: Undefined symbol _syslog referenced from text segment > > log.o: Undefined symbol _openlog referenced from text segment > > > Or maybe I have a FLAG or LIB variable missing... > > Exactly. _Having_ a syslog.a somewhere on some partition isn't quite > sufficient, you also need to tell the compiler/linker to actually _use_ > it. ;-) > Adding -lsyslog to the linker flags should be helpful for that purpose... OK, thanks I have added that and those two erros have disappeared, but now I get:- c:\usr\lib/syslog.a(syslog.o): Undefined symbol _send referenced in text segment. I've tried two different syslog libraries without success. Where should I expect to find the right one? As for syslog.a being somewhere on the partition, I didn't think it mattered where you put it as long as LIBRARY_PATH pointed there... I also expected the patch to change everything I needed, but I guess I was wrong, although maybe running autoconf in the first place would have helped to build the Makefile correctly. Or is that not the case? > Regards, > Stefan > -- > Micro$oft is not an answer. It is a question. The answer is 'no'. > -- John **= Email 11 ==========================** Date: Wed, 18 Dec 2002 13:53:11 +0100 (CET) From: Stefan Neis Subject: Re: Building RSYNC On Wed, 18 Dec 2002, John Poltorak wrote: > gcc -Dstrncasecmp=strnicmp -Dstrcasecmp=stricmp -DHAVE_CONFIG_H -Wall -W > -I./popt -o rsync rsync.o generator.o receiver.o cleanup.o sender.o > exclude.o util.o main.o checksum.o match.o syscall.o log.o backup.o > options.o flist.o io.o compat.o hlink.o token.o uidlist.o socket.o > fileio.o batch.o clientname.o params.o loadparm.o clientserver.o access.o > connection.o authenticate.o lib/fnmatch.o lib/compat.o lib/snprintf.o > lib/mdfour.o lib/permstring.o lib/inet_ntop.o lib/inet_pton.o > lib/getaddrinfo.o lib/getnameinfo.o zlib/deflate.o zlib/infblock.o > zlib/infcodes.o zlib/inffast.o zlib/inflate.o zlib/inftrees.o > zlib/infutil.o zlib/trees.o zlib/zutil.o zlib/adler32.o popt/findme.o > popt/popt.o popt/poptconfig.o popt/popthelp.o popt/poptparse.o -lsocket > log.o: Undefined symbol _syslog referenced from text segment > log.o: Undefined symbol _openlog referenced from text segment > Or maybe I have a FLAG or LIB variable missing... Exactly. _Having_ a syslog.a somewhere on some partition isn't quite sufficient, you also need to tell the compiler/linker to actually _use_ it. ;-) Adding -lsyslog to the linker flags should be helpful for that purpose... Regards, Stefan -- Micro$oft is not an answer. It is a question. The answer is 'no'. **= Email 12 ==========================** Date: Wed, 18 Dec 2002 14:35:02 +0000 From: John Poltorak Subject: Re: Building RSYNC On Wed, Dec 18, 2002 at 03:15:37PM +0100, Yuri Dario wrote: > Hi John, > > >OK, thanks I have added that and those two erros have disappeared, but now > >I get:- > >c:\usr\lib/syslog.a(syslog.o): Undefined symbol _send referenced in text > >segment. > > that's because library order is significant: -lsyslog -lsocket is the correct sequence. Arggggghhhhh!!!!! Why does everything have to be so hard?! OK, I made that change and ended up with an RSYNC file which I ran EMXBIND on to get a RSYNC.EXE eventually. At least I have managed to build it myself, with much help from others. Many thanks for that. What I'd like to know is whether there is some combination of *FLAGS which will automatically create an EXE without needing to run EMXBIND... For other apps, I've achieved this using something like make AR=emxomfar but it didn't work in this case. > Bye, > > Yuri Dario > > /* > * member of TeamOS/2 - Italy > * http://www.quasarbbs.net/yuri > * http://www.teamos2.it > * http://www.opera.com/os2/ > */ -- John **= Email 13 ==========================** Date: Wed, 18 Dec 2002 14:44:54 +0000 From: John Poltorak Subject: PRIMA Prima is an extensible Perl toolkit for multi-platform GUI development. Platforms supported include Linux, Windows NT/9x/2K, ***OS/2*** and UNIX/X11 workstations FreeBSD, IRIX, SunOS, Solaris and others). The toolkit contains a rich set of standard widgets and has emphasis on 2D image processing tasks. A Perl program using PRIMA looks and behaves identically on X, Win32 and OS/2 PM. The toolkit includes a visual builder and a graphic POD viewer on http://www.prima.eu.org/ -- John **= Email 14 ==========================** Date: Wed, 18 Dec 2002 15:15:37 +0100 (CET) From: "Yuri Dario" Subject: Re: Building RSYNC Hi John, >OK, thanks I have added that and those two erros have disappeared, but now >I get:- >c:\usr\lib/syslog.a(syslog.o): Undefined symbol _send referenced in text >segment. that's because library order is significant: -lsyslog -lsocket is the correct sequence. Bye, Yuri Dario /* * member of TeamOS/2 - Italy * http://www.quasarbbs.net/yuri * http://www.teamos2.it * http://www.opera.com/os2/ */ **= Email 15 ==========================** Date: Wed, 18 Dec 2002 15:58:03 +0100 (CET) From: Stefan Neis Subject: Re: Building RSYNC On Wed, 18 Dec 2002, John Poltorak wrote: > On Wed, Dec 18, 2002 at 03:15:37PM +0100, Yuri Dario wrote: > > Hi John, > > > > >OK, thanks I have added that and those two erros have disappeared, but now > > >I get:- > > >c:\usr\lib/syslog.a(syslog.o): Undefined symbol _send referenced in text > > >segment. > > > > that's because library order is significant: -lsyslog -lsocket is the correct sequence. Sorry for not having realized that ... > What I'd like to know is whether there is some combination of *FLAGS which > will automatically create an EXE without needing to run EMXBIND... either use "... -o rsync.exe ..." instead of "... -o rsync ..." (No idea, though, how to get that into the Makefile at the right place, ideally configure should figure that out by itself) or add the famous "-Zexe" to the linker flags. Regards, Stefan -- Micro$oft is not an answer. It is a question. The answer is 'no'. **= Email 16 ==========================** Date: Wed, 18 Dec 2002 16:02:45 +0000 From: John Poltorak Subject: EMX.DLL required? Is there any way I can determine whether a particular binary requires EMX.DLL? -- John **= Email 17 ==========================** Date: Wed, 18 Dec 2002 16:27:16 -0500 From: Ted Sikora Subject: Re: Mailman: update Andrew MacIntyre wrote: > > On Mon, 16 Dec 2002, Ted Sikora wrote: > > > Here's those errors I attched a zip of the locks after running ./newlist > > the first time: > > > > http://powerusersbbs.net/ftp/incoming/locknewlist.gif > > > > After removing the locks and running newlist again it freezes and gives > > this error: > > > > http://powerusersbbs.net/ftp/incoming/newlist2ndrun.gif > > This is quite a mystery! I cannot for the life of me see why this is > failing, but suspect that the cause of both these symptoms is a > file system semantics issue. > > In the first case, we're being told we don't have any rights to update the > timestamp of a file we just created.... > > In the second case, it appears that we hang trying to open a file (Mailman > log) for append. This also makes no sense, as an open should either > succeed or fail in short order.... It fails when trying to send a mail notification to the list owner after making it. > > IIRC, you're running on WSeB. Is the Mailman directory tree on a JFS > volume? Are you using the standard Python22.DLL or the experimental > one I sent you (not that it should matter as most of Mailman is > single-threaded)? The std one. It's on JFS/HPFS386 in WSeB. > > Unfortunately I only have Warp 4.0, and only run HPFS. I've now got a > Mailman installation complete enough to test ./newlist and it works fine. > The locks get created and deleted normally. > > I've attached a minor correctness patch (to Mailman/Utils.py, against the > original source file) which I don't believe is coming into play in your > configuration because you don't have a drive letter in your configured > ${prefix}. > > Can you zip up you Mailman installation (include full paths in the zip) > and put it where I can get it? I can then check whether your build works > on my system. That's the only idea I have right now.... > It's at: http://powerusersbbs.net/ftp/pub/mailman/mailman2013-os2emx-021218.zip -- Ted Sikora tsikora at ntplx.net **= Email 18 ==========================** Date: Wed, 18 Dec 2002 16:58:43 +0000 From: John Poltorak Subject: Re: Building RSYNC On Wed, Dec 18, 2002 at 03:58:03PM +0100, Stefan Neis wrote: > > > >OK, thanks I have added that and those two erros have disappeared, but now > > > >I get:- > > > >c:\usr\lib/syslog.a(syslog.o): Undefined symbol _send referenced in text > > > >segment. > > > > > > that's because library order is significant: -lsyslog -lsocket is the correct sequence. > > Sorry for not having realized that ... > > > What I'd like to know is whether there is some combination of *FLAGS which > > will automatically create an EXE without needing to run EMXBIND... > > either use "... -o rsync.exe ..." instead of "... -o rsync ..." (No idea, > though, how to get that into the Makefile at the right place, ideally > configure should figure that out by itself) or add the famous "-Zexe" to > the linker flags. Now that I've managed to build RSYNC.EXE, I'm aware of three problems which needed to be overcome, ie missing strcasecmp, missing library, and conversion to .EXE. The first can be overcome by adding -Dstrcasecmp=stricmp to CFLAGS and the second by setting %LIBS% to '-lsyslog -lsocket', but I can't come up with the correct FLAGS for creating an EXE, although I've tried a number of things... Setting LDFLAGS='-Zexe causes configure to fail. I thought Autoconf might have worked out which *FLAGS were correct in an OS/2 environment... > Regards, > Stefan > -- > Micro$oft is not an answer. It is a question. The answer is 'no'. > -- John **= Email 19 ==========================** Date: Wed, 18 Dec 2002 17:24:23 +0000 From: John Poltorak Subject: Re: Building RSYNC Hi Ken, On Wed, Dec 18, 2002 at 09:08:04AM -0800, Ken Ames wrote: > hi John, > sure it is, a global solution to a global problem and it is a string > function so it belongs in string.h and anyone competent enough to build > a package can surely edit a file.an updated string.h could be placed on > unixos2 page and made available this way also. just something EM missed > I am sure but nobody is perfect. Looking at strings.h in Posix/2 the missing function is defined. IMV the correct way forwarbid is to replace the EMX headers with the Posix/2 headers, but that seems like a non-trivial task. I don't like the idea of arbitrarily hacking headers since it is likely to introduce further discrepancies into what is already a minefield of different versions of apps which everyone seems to use. > Ken > > > John Poltorak wrote: > > >On Wed, Dec 18, 2002 at 01:56:05AM -0800, Ken Ames wrote: > > > > > >>hi, > >> I added the following to the end of my string.h file since it seemed > >>the correct place for a string function - > >> > >>#if !defined(strcasecmp) > >>#define strcasecmp stricmp > >>#endif > >>#if !defined(strncasecmp) > >>#define strncasecmp strnicmp > >>#endif > >> > >>haven't had any troubles with that, hth. > >> > >> > > > >It may well work, but I don't think it is the correct way of addressing > >the problem. -- John **= Email 20 ==========================** Date: Wed, 18 Dec 2002 19:01:34 -0500 From: Thomas Dickey Subject: Re: Terminal choices On Tue, Dec 17, 2002 at 07:19:35PM +0000, John Poltorak wrote: > When building LESS (v378) there is a choice of terminal libraries to use > which include xcurses, ncurses, termcap and termlib. xcurses is usually the vendor's implementation of X/Open curses, which is not 100% compatible with older versions of curses. termlib is usually either the terminfo-only portion of the curses+terminfo library, or an alias (symbolic link) to the same library. -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net **= Email 21 ==========================** Date: Wed, 18 Dec 2002 19:02:26 -0500 From: Thomas Dickey Subject: Re: Ncurses ticdir On Tue, Dec 17, 2002 at 06:47:08AM -0500, Thomas E. Dickey wrote: > On Tue, 17 Dec 2002, John Poltorak wrote: > > > > > Having just built Ncurses using prefix=/usr/local2, I see that > > > > ticdir=u:/usr/share/terminfo > > > > u: is the current drive, but I don't see anywhere that ticdir is set, so I > > guess there is a default. > > > > In this case boththe tabset and terminfo directories are empty. Here are > > the errors I get:- > > I see at least one problem in the (generated) run_tic.sh script. > It's using sed with ':' as a delimiter to translate the $TABSET value, > which probably is making it fail when $TABSET contains a ':'. > I'll check on that this evening and see about sending you a short > diff to repair it. (There are also some cases where it uses ' at ' > as a delimiter, which should work, but I would rather make them > consistently '%'). I think the problem is only in one file - here's a suggested patch: --- /usr/build/ncurses/ncurses-5.3-20021012-os2/misc/run_tic.in 2001-10-13 20:44:33.000000000 -0400 +++ run_tic.in 2002-12-18 18:55:35.000000000 -0500 at at -81,7 +81,7 at at umask 022 # Construct the name of the old (obsolete) pathname, e.g., /usr/lib/terminfo. -TICDIR=`echo $TERMINFO | sed -e 's at /share/ at /lib/ at '` +TICDIR=`echo $TERMINFO | sed -e 's%/share/%/lib/%'` # Remove the old terminfo stuff; we don't care if it existed before, and it # would generate a lot of confusing error messages if we tried to overwrite it. at at -91,11 +91,11 at at # If we're not installing into /usr/share/, we'll have to adjust the location # of the tabset files in terminfo.src (which are in a parallel directory). -TABSET=`echo $ticdir | sed -e 's at /terminfo$ at /tabset at '` +TABSET=`echo $ticdir | sed -e 's%/terminfo$%/tabset%'` if test "x$TABSET" != "x/usr/share/tabset" ; then echo '** adjusting tabset paths' TMP=${TMPDIR-/tmp}/$$ - sed -e s:/usr/share/tabset:$TABSET:g $source >$TMP + sed -e s%/usr/share/tabset%$TABSET%g $source >$TMP trap "rm -f $TMP" 0 1 2 5 15 source=$TMP fi at at -140,9 +140,9 at at cd ${DESTDIR}$prefix # Construct a symbolic link that only assumes $ticdir has the # same $prefix as the other installed directories. - RELATIVE=`echo $ticdir|sed -e 's:^'$prefix'/::'` + RELATIVE=`echo $ticdir|sed -e 's%^'$prefix'/%%'` if test "$RELATIVE" != "$ticdir" ; then - RELATIVE=../`echo $ticdir|sed -e 's:^'$prefix'/::' -e 's:^/::'` + RELATIVE=../`echo $ticdir|sed -e 's%^'$prefix'/%%' -e 's%^/%%'` fi if ( at LN_S at $RELATIVE $TICDIR ) then -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net **= Email 22 ==========================** Date: Wed, 18 Dec 2002 19:16:38 +0000 From: John Poltorak Subject: Posix/2 v. EMX includes What would be wrong with replacing my emx\include dir with Posix/2's libext\include for standard headers? -- John **= Email 23 ==========================** Date: Wed, 18 Dec 2002 19:27:01 CET From: Illya Vaes Subject: Re: EMX.DLL required? ** Reply to note from John Poltorak Wed, 18 Dec 2002 16:02:45 +0000 >Is there any way I can determine whether a particular binary requires >EMX.DLL? CHKDLL32 on Hobbes. eg.: [e:\tk8.3.5\os2]chkdll32 c:\Tcl805\bin\wish80.exe Loading DLL 'tk80' --> C:\TCL805\BIN\TK80.DLL. Loading DLL 'tcl80' --> C:\TCL805\BIN\TCL80.DLL. Loading DLL 'EMXLIBCM' --> D:\OS2UTILS\DLL\EMXLIBCM.DLL. Loading DLL 'pmwin' --> C:\OS2\DLL\PMWIN.DLL. Loading DLL 'emx' --> D:\OS2UTILS\DLL\EMX.DLL. All DLL's used by 'c:\Tcl805\bin\wish80.exe' could be loaded. and: [e:\tk8.3.5\os2]chkdll32 c:\Tcl805\bin\tk80.dll Loading DLL 'PMWIN' --> C:\OS2\DLL\PMWIN.DLL. Loading DLL 'tcl80' --> C:\TCL805\BIN\TCL80.DLL. Loading DLL 'EMXLIBCM' --> D:\OS2UTILS\DLL\EMXLIBCM.DLL. Loading DLL 'doscalls' --> loaded. Loading DLL 'pmgpi' --> C:\OS2\DLL\PMGPI.DLL. Loading DLL 'pmshapi' --> C:\OS2\DLL\PMSHAPI.DLL. Loading DLL 'pmwin' --> C:\OS2\DLL\PMWIN.DLL. Loading DLL 'pmctls' --> C:\OS2\DLL\PMCTLS.DLL. Loading DLL 'emx' --> D:\OS2UTILS\DLL\EMX.DLL. All DLL's used by 'c:\Tcl805\bin\tk80.dll' could be loaded. -- Illya Vaes (illya at vaeshiep.demon.nl) "Do...or do not, there is no 'try'" - Yoda **= Email 24 ==========================** Date: Wed, 18 Dec 2002 20:57:18 +0000 From: John Poltorak Subject: Re: EMX.DLL required? On Wed, Dec 18, 2002 at 07:27:01PM +0100, Illya Vaes wrote: > ** Reply to note from John Poltorak Wed, 18 Dec 2002 16:02:45 > +0000 > >Is there any way I can determine whether a particular binary requires > >EMX.DLL? > > CHKDLL32 on Hobbes. Thanks for the pointer... but it's actually an IBM program and not available from Hobbes. Google should find it though. > -- > Illya Vaes (illya at vaeshiep.demon.nl) > "Do...or do not, there is no 'try'" - Yoda -- John **= Email 25 ==========================** Date: Wed, 18 Dec 2002 22:19:31 +0100 (CET) From: Stefan Neis Subject: Re: Posix/2 v. EMX includes On Wed, 18 Dec 2002, John Poltorak wrote: > What would be wrong with replacing my emx\include dir with Posix/2's > libext\include for standard headers? There are two problems: 1. Using Posix/2 headers often results in dependencies on cExt.a, i.e. just replacing the headers and not linking against the library typically will not work. 2. I don't really know how complete the Posix/2 header are (e.g. there's no os2.h as that won't be needed in compiling a unix application). Over here I have Posix/2's include dir (when using Posix/2) in front of emx include dir, but I do have the later as a backup for headers not found under posix/2. So just replacing won't quite do, you would have to carefully merge those directories together. Regards, Stefan -- Micro$oft is not an answer. It is a question. The answer is 'no'. **= Email 26 ==========================** Date: Wed, 18 Dec 2002 22:26:11 +0100 (CET) From: Stefan Neis Subject: Re: Building RSYNC On Wed, 18 Dec 2002, John Poltorak wrote: > > either use "... -o rsync.exe ..." instead of "... -o rsync ..." (No idea, > > though, how to get that into the Makefile at the right place, ideally > > configure should figure that out by itself) (snipp) > I thought Autoconf might have worked out which *FLAGS were correct in an > OS/2 environment... Yes, in theory it should know that OS/2 builds executables with ".exe" as extension, but apparently the Makefile (or rather Makefile.in) makes no use of that knowledge and tries to build plain "rsync" nonetheless. Sounds like a bug/missing feature in either rync's Makefile.in or even in its configure.in. :-( Regards, Stefan -- Micro$oft is not an answer. It is a question. The answer is 'no'. **= Email 27 ==========================** Date: Wed, 18 Dec 2002 23:04:01 +1000 (est) From: Andrew MacIntyre Subject: Re: Mailman: update This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime at docserver.cac.washington.edu for more info. ---888574994-7278-1040216641=:973 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 16 Dec 2002, Ted Sikora wrote: > Here's those errors I attched a zip of the locks after running ./newlist > the first time: > > http://powerusersbbs.net/ftp/incoming/locknewlist.gif > > After removing the locks and running newlist again it freezes and gives > this error: > > http://powerusersbbs.net/ftp/incoming/newlist2ndrun.gif This is quite a mystery! I cannot for the life of me see why this is failing, but suspect that the cause of both these symptoms is a file system semantics issue. In the first case, we're being told we don't have any rights to update the timestamp of a file we just created.... In the second case, it appears that we hang trying to open a file (Mailman log) for append. This also makes no sense, as an open should either succeed or fail in short order.... IIRC, you're running on WSeB. Is the Mailman directory tree on a JFS volume? Are you using the standard Python22.DLL or the experimental one I sent you (not that it should matter as most of Mailman is single-threaded)? Unfortunately I only have Warp 4.0, and only run HPFS. I've now got a Mailman installation complete enough to test ./newlist and it works fine. The locks get created and deleted normally. I've attached a minor correctness patch (to Mailman/Utils.py, against the original source file) which I don't believe is coming into play in your configuration because you don't have a drive letter in your configured ${prefix}. Can you zip up you Mailman installation (include full paths in the zip) and put it where I can get it? I can then check whether your build works on my system. That's the only idea I have right now.... -- Andrew I MacIntyre "These thoughts are mine alone..." E-mail: andymac at bullseye.apana.org.au | Snail: PO Box 370 andymac at pcug.org.au | Belconnen ACT 2616 Web: http://www.andymac.org/ | Australia ---888574994-7278-1040216641=:973 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="Mailman_Utils.py.patch.v2" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Mailman_Utils.py.patch.v2 Content-Disposition: attachment; filename="Mailman_Utils.py.patch.v2" KioqIFV0aWxzLnB5Lm9yaWcJRnJpIEp1bCAxMiAwODo0NDoyOCAyMDAyDQot LS0gVXRpbHMucHkJV2VkIERlYyAxOCAyMjozODo0NCAyMDAyDQoqKioqKioq KioqKioqKioNCioqKiAyNTMsMjU4ICoqKioNCi0tLSAyNTMsMjY3IC0tLS0N CiAgZGVmIE1ha2VEaXJUcmVlKHBhdGgsIHBlcm1zPTA3NzUsIHZlcmJvc2U9 MCk6DQogICAgICBtYWRlX3BhcnQgPSAnLycNCiAgICAgIHBhdGhfcGFydHMg PSBmaWx0ZXIoTm9uZSwgc3RyaW5nLnNwbGl0KHBhdGgsICcvJykpDQorICAg ICBpZiBvcy5uYW1lIGluICgnb3MyJywpOg0KKyAgICAgICAgIG1hZGVfcGFy dCA9ICcnDQorICAgICAgICAgdHJ5Og0KKyAgICAgICAgICAgICBwYXRoXzAg PSBwYXRoX3BhcnRzWzBdDQorICAgICAgICAgICAgIGlmIHBhdGhfMFsxXSA9 PSAnOic6DQorICAgICAgICAgICAgICAgICBtYWRlX3BhcnQgPSBwYXRoXzAg KyAnLycNCisgICAgICAgICAgICAgICAgIHBhdGhfcGFydHMgPSBwYXRoX3Bh cnRzWzE6XQ0KKyAgICAgICAgIGV4Y2VwdCBJbmRleEVycm9yOg0KKyAgICAg ICAgICAgICBwYXNzDQogICAgICBmb3IgaXRlbSBpbiBwYXRoX3BhcnRzOg0K ICAJbWFkZV9wYXJ0ID0gb3MucGF0aC5qb2luKG1hZGVfcGFydCwgaXRlbSkN CiAgCWlmIG9zLnBhdGguZXhpc3RzKG1hZGVfcGFydCk6DQo= ---888574994-7278-1040216641=:973-- **= Email 28 ==========================** Date: Wed, 18 Dec 2002 23:13:04 +0100 From: Thomas Hoffmann Subject: Re: R John, on Oct, 28th I answered a similar question from Peter Milne and cc'd this (rather detailed) answer to this list. If it did not get lost you should be able to find it. I made some more progress since then and now have a running R-1.6.1 on my OS/2 (eCS) machine here. If anybody is really interested in statistical computing unde OS/2 then do not hesitate to ask further questions. John Poltorak wrote: > > Anyone familiar with the R project? See:- > > http://www.r-project.org > > Would any of it build on OS/2? I don't suppose anyone has already ported > it... >