From: UnixOS2 Archive To: "UnixOS2 Archive" Date: Mon, 20 Jan 2003 04:48:44 EST-10EDT,10,-1,0,7200,3,-1,0,7200,3600 Subject: [UnixOS2_Archive] No. 19 ************************************************** Sunday 19 January 2003 Number 19 ************************************************** Subjects for today 1 Re: glibc completion : Andreas Buening 2 Re: Autoconf & Make 3.76.1 : Andreas Buening 3 Re: UnixOS/2 Build System - mailing list : IanM" 4 Re: UnixOS/2 Build System - mailing list : IanM" 5 Re: UnixOS/2 Build System - mailing list : IanM" 6 Re: TERMCAP.DAT : Thomas Dickey 7 Re: glibc completion : John Poltorak 8 Standard variables : John Poltorak 9 Re: glibc completion : nickk" 10 Re: glibc completion : John Poltorak 11 Re: Standard variables : Dave Saville" 12 Re: glibc completion : Stefan Neis 13 Re: Building PERL using Posix/2 : Stefan Neis 14 Re: glibc completion : Holger Veit 15 Re: glibc completion : Holger Veit 16 Adding new file via patch : John Poltorak 17 Re: TERMCAP.DAT : Patrick Ash 18 Re: Building OpenSSL : Patrick Ash 19 Re: TERMCAP.DAT : Thomas Dickey 20 Re: Autoconf & Make 3.76.1 : John Poltorak 21 Open Group's commands and utils : John Poltorak 22 Building OpenSSL : John Poltorak 23 Re: TERMCAP.DAT : Nicholas Sheppard 24 Announcement: Pine 4.53 : Nicholas Sheppard 25 Re: Adding new file via patch : Thomas Hoffmann 26 Re: Syntax of bldlevel string : Thomas Hoffmann **= Email 1 ==========================** Date: Mon, 20 Jan 2003 01:14:45 +0100 From: Andreas Buening Subject: Re: glibc completion Stefan Neis wrote: > > On Fri, 17 Jan 2003, Bart van Leeuwen wrote: > > > I think this is a major issue, I run into incompatibilites and missing > > parts off the glibc version we use with EMX. > > For the 316th time: There is no such thing as _G_libc that is used with > EMX. It's using it's own libc which has no relation at all with the GNU > version of libc. That's not the point. If I encounter one of those missing functions I also don't check whether it's Posix I/II, SysV, GNU, Unix98 or whathever. I look at glibc or at some Unix manpages to find out what this function is doing. Then I know that the glibc function foo() is missing. > > A roadmap for this has to be discussed, otherwise we > > end up making the same mistakes over and over again. > > Actually, the current proposal would be to try using the > POSIX/2 library (cExt.a). That's based on BSD libc, again > totally unrelated to GNU libc, but about as complete as it can > get - and I would be surprised if the dhcp client really required > _GNU_ libc, as that would imply that Linux and Hurd would be > about the only systems being able to compile it.... > > Note that POSIX/2's cExt.a has some rather annoying bugs in > some of the more esoteric functions. I hope to be able to > integrate a couple of patches during this weekend ... Okay, let's summarize the facts: - There are lots of missing functions. There have been several postings by several developers about functions that were missing in project xy. For every such posting you can consider at least 10 other people having the same problem, implementing the same function for another project. - LIBEMU is (still) vaporware. Nobody knows what's its current state. Even if it came out tomorrow it would need a long time (at least a year) until it could be considered as "ready for production use", I guess. Personally, I don't expect anything before 2005. - The only stable libc we have is EMX. It's outdated but stable. - EMX seems to be abandoned. So we could take over the development. - We need a reasonable build system. This especially means we need a working and consistent set of header files. Switching between different include directories because header file xyz of project bla is better for compiling foo than header file blurb is not acceptable. That's hard to maintain and absolutely confusing. The only people who may have to switch header files at runtime are the compiler or libc developers. This leads to the conclusions: - We need an improved libc NOW. - We need a consistent set of header files. I can see the following possible solutions: 1. We take over EMX as is and improve it. This means we add new function declarations to the header files, we add new functions to the emx*.dll files while preserving binary backward compatibility. Advantages: We can start from a working libc and can improve it function by function, header file by header file. We have ONE set of header files. No need for extra compiler flags because everything is already in EMX. Disadvantages: More frequent updates of the EMX runtime. Programs using the new functions wouldn't work with the old EMX dlls but also programs compiled with Posix/2 or Libemu wouldn't work without the new dlls. 2. We keep EMX untouched but we add all new functionality to an additional library called unixos2.dll. Advantages: We can start from a working libc and can improve it function by function, header file by header file. We can reuse the EMX headers (and adding some new function declarations to them without affecting compatibility) and can add new header files. No updates of the EMX dlls anymore. Never. Disadvantages: Need for an extra compiler flag "-lunixos2". 3. We keep EMX untouched but we add all new functionality to an additional library called Posix/2. Advantages: We have a huge bunch of already implemented additional functions. No updates of the EMX dlls anymore. Never. Disadvantages: We can't start from a working libc but I don't know whether the bugs in Posix/2 are really serious. Need for an extra compiler flag "-lext". We have a completely new set of header files, i.e. all EMX headers have to be replaced. Question: Does Posix/2 support all documented EMX functions, i.e. is it possible to compile all kinds of EMX programs with Posix/2? 4. We do nothing. We wait for LIBEMU, and lots of programs can't be compiled. Maybe we'll have to wait for years. Now, it's time for a decision. I hope I've mentioned the most important points. So the question What do we want? Personally, I'd vote for 1 or 2 but that's not the point. It's much more important to make a decision and to have more than developer moving into that direction. 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: Mon, 20 Jan 2003 01:16:09 +0100 From: Andreas Buening Subject: Re: Autoconf & Make 3.76.1 John Poltorak wrote: > > I realise the README for Autoconf says that Make v3.79.1+ is required to > build Autoconf, but I'm trying to understand why... Maybe because older versions don't work? > With fixed versions of Make 3.76.1, building Autoconf goes quite well up > to a certain point and part of the app actually gets installed, but then > Make goes into some strange loop. > > Can anyone explain what the problem is? I've tried to follow what happens > but get hopelessly tied up in knots. > > The build sequence goes fine until:- > > Making install in bin > Making install in tests > Making install in . > > and then it goes into a continuous loop:- > > Making install in bin > Making install in tests > Making install in . > Making install in bin > Making install in tests > Making install in . > Making install in bin > Making install in tests > Making install in . > Making install in bin > > Is there any way to trace what is happening and why? Sure. "make -d" and lots of debugging. But why do you want to play around with older versions if the latest ones work? 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: Mon, 20 Jan 2003 01:17:38 +1100 (EDT) From: "IanM" Subject: Re: UnixOS/2 Build System - mailing list Hi John I've been away, where is this other list, I'd hate to search through all those posts :-( Cheers IanM http://www.os2site.com/ What's a 1000 lawyers at the bottom of the ocean? -- A good start **= Email 4 ==========================** Date: Mon, 20 Jan 2003 02:43:39 +1100 (EDT) From: "IanM" Subject: Re: UnixOS/2 Build System - mailing list Hi John >> I've been away, >Thought you were a bit quiet... Who me, I'm always quiet :-) >http://powerusersbbs.net/mailman/listinfo/ux2bs Thanks Looks like everyones been very busy, even os2site's incoming and new directorys have had an average 47 new files uploaded every week that I've been away, and the last 7 days had 76 files uploaded ! Ted looks like he has been the busiest of all. Cheers IanM http://www.os2site.com/ "ME or THAT computer" she said... that was yesterday... **= Email 5 ==========================** Date: Mon, 20 Jan 2003 02:43:39 +1100 (EDT) From: "IanM" Subject: Re: UnixOS/2 Build System - mailing list Hi John >> I've been away, >Thought you were a bit quiet... Who me, I'm always quiet :-) >http://powerusersbbs.net/mailman/listinfo/ux2bs Thanks Looks like everyones been very busy, even os2site's incoming and new directorys have had an average 47 new files uploaded every week that I've been away, and the last 7 days had 76 files uploaded ! Ted looks like he has been the busiest of all. Cheers IanM http://www.os2site.com/ "ME or THAT computer" she said... that was yesterday... **= Email 6 ==========================** Date: Mon, 20 Jan 2003 07:01:23 -0500 From: Thomas Dickey Subject: Re: TERMCAP.DAT On Sun, Jan 19, 2003 at 09:15:49PM +0000, John Poltorak wrote: > > Ncurses includes a file, terminfo.src, which, as I understand is used as a > definitive source for any terminal definition you should ever need... > > > Within it, it mentions:- > > > #### Non-Unix Consoles > # > > # Except for the "-emx" suffixes, these are as distributed with EMX 0.9b, > # a Unix-style environment used on OS/2. (Note that the suffix makes some > # names longer than 14 characters, the nominal maximum). > # > # Removed: rmacs=\E[10m, smacs=\E[11m, because OS/2 does not implement > acs. > ansi-emx|ANSI.SYS color, > > > So presumably there is some relationship between this section and > TERMCAP.DAT which come with EMX... But I don't see it at all. not much. termcap.dat is built/customized by hand. The emx.src file in ncurses corresponds roughly (some corrections and additions) to termcap.dat on OS/2. It isn't directly incorporated into terminfo.src because (iirc) some of the so-called "ansi" entries don't follow the conventions that 99% of the users would expect. Sometime I might merge the corrected entries into terminfo.src and generate subsets of it for installing. -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net **= Email 7 ==========================** Date: Mon, 20 Jan 2003 10:22:28 +0000 From: John Poltorak Subject: Re: glibc completion On Sun, Jan 19, 2003 at 07:55:54PM -0500, Henry Sobotka wrote: > The main disadvantage I see to #1 is the risk of EM suddenly popping up > with another fix or revision of EMX, as happened the last time we got > into discussion of it as abandonware. Were that to happen, we'd have two > EMXes. Does anyone have contact with EM? It would be nice to know what future plans he has, if any... Does he still use OS/2 himself? > h~ -- John **= Email 8 ==========================** Date: Mon, 20 Jan 2003 12:09:02 +0000 From: John Poltorak Subject: Standard variables Is there anything which defines which environment variables should/must be present on a Unix system? -- John **= Email 9 ==========================** Date: Mon, 20 Jan 2003 13:13:36 +0300 (MSK) From: "nickk" Subject: Re: glibc completion Hi! I vote for another variant - ask Holger to release uncompleted libemu and we could participate in it to get it completed before we die ;) **= Email 10 ==========================** Date: Mon, 20 Jan 2003 14:29:58 +0000 From: John Poltorak Subject: Re: glibc completion On Mon, Jan 20, 2003 at 03:13:17PM +0100, Stefan Neis wrote: > And my answer to both is: Posix/2 is there, so what's the problem > (aside from debugging & fixing)? Just install it on your system, > modify C_INCLUDE_PATH, CPLUS_INCLUDE_PATH, LIBRARY_PATH and you're > done. Of course, one could melt all those functions into emx.dll/ > emxc?.dll, but why not debug them first? I was hoping that my build system would provide an opportunity to do this... Unfortunately building Perl didn't get very far at all. Should I expect it to work? Maybe I missed something out... > Ah, OK, reading further, I get it, you're annoyed by the extra -lcExt > which I just forgot about ... Exactly where would I need to include this -lcExt if I wanted to build Perl using Posix/2? > Regards, > Stefan -- John **= Email 11 ==========================** Date: Mon, 20 Jan 2003 14:31:59 +0000 (GMT) From: "Dave Saville" Subject: Re: Standard variables On Mon, 20 Jan 2003 12:09:02 +0000, John Poltorak wrote: > >Is there anything which defines which environment variables should/must be >present on a Unix system? I could be wrong but I don't think so - at least I never ran across anything in five years of Solaris systems admin. I think it depends on how the system was setup, what the default shell is and what gets sourced at login/shell start. Note that these are two different events. There are default startup scripts for all the usual shells, buried somewhere under /etc. Thats most likely the nearest you will get - and they likely differ between flavours of *nix - or even versions of the same *nix. If you start a bourne shell progamatically about the only one around is $HOME - I assume so that one can start sourcing things. -- Regards Dave Saville **= Email 12 ==========================** Date: Mon, 20 Jan 2003 15:13:17 +0100 (CET) From: Stefan Neis Subject: Re: glibc completion On Mon, 20 Jan 2003, Andreas Buening wrote: > Then I know that the glibc function foo() > is missing. But that makes it sound like it's a glibc-specific extension of libc, which implies that something is really wrong as almost all packages I know should build with any libc used on Unix, not just with glibc. So, if it's a general libc function, then it is in fact missing, if it's an extension to libc provided (only) by glibc, then something is conigured wrongly, that's why I insist on that seemingly silly difference... > This leads to the conclusions: > - We need an improved libc NOW. > - We need a consistent set of header files. And my answer to both is: Posix/2 is there, so what's the problem (aside from debugging & fixing)? Just install it on your system, modify C_INCLUDE_PATH, CPLUS_INCLUDE_PATH, LIBRARY_PATH and you're done. Of course, one could melt all those functions into emx.dll/ emxc?.dll, but why not debug them first? Ah, OK, reading further, I get it, you're annoyed by the extra -lcExt which I just forgot about ... > 3. We keep EMX untouched but we add all new functionality to an > additional library called Posix/2. > Advantages: We have a huge bunch of already implemented > additional functions. No updates of the EMX dlls anymore. Never. > Disadvantages: We can't start from a working libc Actually, it's based on EMX dll's which work reasonably well ... > but I don't > know whether the bugs in Posix/2 are really serious. > Need for an extra compiler flag "-lext". > We have a completely new set of header files, i.e. all EMX > headers have to be replaced. Question: Does Posix/2 support > all documented EMX functions, i.e. is it possible to compile > all kinds of EMX programs with Posix/2? Actually, we are linking against _both_ cExt.a (first) _and_ EMX standard libraries (afterwards, catching anything not touched by cExt or where cExt.a really is just a wrapper), so there shouldn't be any problem with any existing program. The first that can happen is that we end up with a mix of incompatible function (one from BSD, one from EMX or even from the native OS/2 level) which cause strange runtime errors (we had/fixed that kind of problem with e.g. sockets, Thomas seems to have one or two occurences of a similar problem, unfortunately, II had no time to look into it, so far). > important points. So the question What do we want? Personally, > I'd vote for 1 or 2 but that's not the point. If somebody has time/knowledge to do this, that would be my prefered way as well, but it's like to take quite some time, so in the meantime, I'll happily stay with what already exists (Posix/2). Regards, Stefan **= Email 13 ==========================** Date: Mon, 20 Jan 2003 15:27:55 +0100 (CET) From: Stefan Neis Subject: Re: Building PERL using Posix/2 On Sun, 19 Jan 2003, John Poltorak wrote: > hv.c:82: warning: implicit declaration of function `offsetof' > hv.c:82: parse error before `HEK' > hv.c:82: parse error before `)' Sounds like somewhere in the new includes there's a missing #define or a define too much which causes either something which needs to be expanded to get valid C code to not be expanded, or something which already is valid C code gets expanded to some nonsense... :-( I'll try to give it a try, when I'm back at my OS/2 box... Regards, Stefan -- Micro$oft is not an answer. It is a question. The answer is 'no'. **= Email 14 ==========================** Date: Mon, 20 Jan 2003 15:52:15 +0100 From: Holger Veit Subject: Re: glibc completion On Sun, Jan 19, 2003 at 07:55:54PM -0500, Henry Sobotka wrote: > My preference is for #2. Supplying the missing pieces seems more > manageable than an entire library such as Posix/2, which already has > incompatibilities with EMX (e.g. struct stat) but could be cannibalized > where useful. Effectively, whether you call the thing -lunixos2 or -lcExt or -lemu is irrelevant - they basically take something from EMX and add own extensions. Posix/2 has shown the following: If you leave EMX untouched, then you will unavoidably get incompatibility. Yes, this *will* definitely happen also with Unixos2.dll. You also *must* override certain functionality and replace other functionality of EMX there (for instance symlinks to work will require either kernel work or replacement of the filename handling code in EMX). Otherwise the Unixos2.dll will become a teethless tiger that mainly just replaces uncritical stricmp with strcasecmp stuff (don't waste time with the attempt of cascading unixos2 and emx, i.e by providing "open()" from unixos2 and then let it fallback to "_open()" in EMX via ordinal import: sounds clever, but will fail where EMX doesn't fully expose its internal structures - e.g. for integration of new system calls). > The main disadvantage I see to #1 is the risk of EM suddenly popping up > with another fix or revision of EMX, as happened the last time we got > into discussion of it as abandonware. Were that to happen, we'd have two > EMXes. It is a matter of 2 minutes editing of the makefile of EMX to rename the produced libraries from EMX.DLL to EMU.DLL and EMXLIBC{MS}.DLL to EMULIBC{S,M}.DLL (or whatever you prefer) to get an offspring which you can freely mess with. Likewise, you just need to edit some lines in the compiler driver code "gcc.c" to have it link against "emu" and "emu2", not "emx" and "emx2". And let EM suddenly pop up with a new version (personally, I doubt, EMX will ever see version 1.0): who then cares if the runtime system UnixOS/2 ships some EMU.DLL and EMULIBC{S,M}.DLL versions. With conversion from an "X" to a "U" (that's vice versa to the Roman proverb ;-) ), it is even possible to convert all existing EMX binaries to EMU binaries, as long as EMX and EMU are the same - this is trivial binary patching of the appropriate table (BTDT) in the executable. Identity of EMU and EMX will change eventually, of course. Holger -- Please update your tables to my new e-mail address: holger.veit$ais.fhg.de (replace the '$' with ' at ' -- spam-protection) **= Email 15 ==========================** Date: Mon, 20 Jan 2003 15:56:19 +0100 From: Holger Veit Subject: Re: glibc completion On Mon, Jan 20, 2003 at 10:22:28AM +0000, John Poltorak wrote: > On Sun, Jan 19, 2003 at 07:55:54PM -0500, Henry Sobotka wrote: > > > The main disadvantage I see to #1 is the risk of EM suddenly popping up > > with another fix or revision of EMX, as happened the last time we got > > into discussion of it as abandonware. Were that to happen, we'd have two > > EMXes. > > Does anyone have contact with EM? It would be nice to know what future > plans he has, if any... Does he still use OS/2 himself? From his few comments in emxlist, I believe he only uses EMX as a reference platform for compatibility. He once remarked that when he finds a discrepency between some Unix libc and EMX, then EMX is typically correct concerning "the standard" (I think he used to talk about outdated Solaris versions that time). Whether he still uses OS/2 I don't know - maybe - but this is irrelevant. Holger -- Please update your tables to my new e-mail address: holger.veit$ais.fhg.de (replace the '$' with ' at ' -- spam-protection) **= Email 16 ==========================** Date: Mon, 20 Jan 2003 16:38:54 +0000 From: John Poltorak Subject: Adding new file via patch How do I go about adding a new file to a distribution via a patch file? Normally if there is a new file, the patch file will say something like:- Only in .: Makefile.emx Is there a way of including the missing file and getting patch to create it? -- John **= Email 17 ==========================** Date: Mon, 20 Jan 2003 17:16:11 +0000 From: Patrick Ash Subject: Re: TERMCAP.DAT On Mon, 20 Jan 2003 07:01:23 -0500, Thomas Dickey wrote: >On Sun, Jan 19, 2003 at 09:15:49PM +0000, John Poltorak wrote: >> #### Non-Unix Consoles >> # >> >> # Except for the "-emx" suffixes, these are as distributed with EMX 0.9b, >> # a Unix-style environment used on OS/2. (Note that the suffix makes some >> # names longer than 14 characters, the nominal maximum). >> # >> # Removed: rmacs=\E[10m, smacs=\E[11m, because OS/2 does not implement >> acs. >> ansi-emx|ANSI.SYS color, >> >> >> So presumably there is some relationship between this section and >> TERMCAP.DAT which come with EMX... But I don't see it at all. > >not much. termcap.dat is built/customized by hand. The emx.src file in >ncurses corresponds roughly (some corrections and additions) to termcap.dat on >OS/2. It isn't directly incorporated into terminfo.src because (iirc) some of >the so-called "ansi" entries don't follow the conventions that 99% of the users >would expect. Sometime I might merge the corrected entries into terminfo.src >and generate subsets of it for installing. > I built all of the terminal entries in term.src when I built ncurses-5.3 (all 2400+ of them) I only tested a couple of them, and found that they left remnants of previous screens, did not display everything properly aligned, and generally showed unacceptable anomolies with regard to screen presentation. Pat -- Patrick Ash patash at comcast.net This OS/2 system uptime is 57 days, 22:12 hours and 31 seconds **= Email 18 ==========================** Date: Mon, 20 Jan 2003 17:24:02 +0000 From: Patrick Ash Subject: Re: Building OpenSSL Brian havard's work has been incorporated into 0.9.7. It will compile out of the box if one follows the instructions. The only caveat is that if one uses gcc 2.9x or 3.x, one of the CFLAGS variables is no longer supported. One needs to change the -m486 to -mcpu=486 in /util/pl/os2-emx.pl Pat On Mon, 20 Jan 2003 20:18:29 +0000, John Poltorak wrote: > >Has anyone tried building OpenSSL according to the instructions here:- > >http://silk.apana.org.au/apache/building-openssl.html > >I tried but couldn't get the patch applied... > >Looking at OpenSSL web site there seems to be a lot of versions to choose >from, and maybe the patch only works on a specific release. > >Which release should I download? -- Patrick Ash patash at comcast.net This OS/2 system uptime is 57 days, 22:20 hours and 22 seconds **= Email 19 ==========================** Date: Mon, 20 Jan 2003 17:40:24 -0500 From: Thomas Dickey Subject: Re: TERMCAP.DAT --qDbXVdCdHGoSgWSk Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Mon, Jan 20, 2003 at 05:16:11PM +0000, Patrick Ash wrote: > On Mon, 20 Jan 2003 07:01:23 -0500, Thomas Dickey wrote: > >not much. termcap.dat is built/customized by hand. The emx.src file in > >ncurses corresponds roughly (some corrections and additions) to termcap.dat on > >OS/2. It isn't directly incorporated into terminfo.src because (iirc) some of > >the so-called "ansi" entries don't follow the conventions that 99% of the users > >would expect. Sometime I might merge the corrected entries into terminfo.src > >and generate subsets of it for installing. > > > > I built all of the terminal entries in term.src when I built > ncurses-5.3 (all 2400+ of them) I only tested a couple of them, and > found that they left remnants of previous screens, did not display > everything properly aligned, and generally showed unacceptable > anomolies with regard to screen presentation. well, to actually test all of them, you'd have to have the appropriate terminals. (I've tested several dozen of the entries - but that's only a small fraction). I use the attached script occasionally to build a mini-database - that's about half of the entries I've tested (the others are cases I can test only on certain machines). -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net --qDbXVdCdHGoSgWSk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=load-terminfo #!/bin/sh # uses the -e switch on tic to selectively load descriptions that are # interesting for my testing. if test -f terminfo.src ; then TMP=/tmp/load$$ trap "rm -f $TMP" 0 1 2 5 15 tic -x -s -1 -I -e' ansi, ansi-m, beterm, color_xterm, decansi, dtterm, ecma+color, klone+acs, klone+color, klone+sgr, klone+sgr-dumb, kterm, linux, linux-c, linux-c-nc, mterm, nxterm, pcansi-m, rxvt, rxvt-basic, screen, screen.xterm-xfree86, screen.teraterm, tek4012, tek4014, vt52, vt100, vt102, vt220, xterm-xf86-v32, xterm-xf86-v33, xterm-xf86-v333, xterm-xf86-v40, xterm-basic, xterm-bold, xterm-8bit, xterm-16color, xterm-24, xterm-r5, xterm-r6, xterm-rep, xterm-x11r6, xterm-xfree86' terminfo.src |egrep -v '^ mem[ul]=.E.,' >$TMP cat >>$TMP < Subject: Re: Autoconf & Make 3.76.1 On Mon, Jan 20, 2003 at 01:16:09AM +0100, Andreas Buening wrote: > John Poltorak wrote: > > > > I realise the README for Autoconf says that Make v3.79.1+ is required to > > build Autoconf, but I'm trying to understand why... > > Maybe because older versions don't work? Yes, but I would like to know what the problem is. An older version of Make has no problem building Perl 5.8.0, and the same version can be used to build Autoconf 2.50. I would not expect Autoconf to be particularly demanding of Make's capabilities... > > With fixed versions of Make 3.76.1, building Autoconf goes quite well up > > to a certain point and part of the app actually gets installed, but then > > Make goes into some strange loop. > > > > Can anyone explain what the problem is? I've tried to follow what happens > > but get hopelessly tied up in knots. > > Is there any way to trace what is happening and why? > > Sure. "make -d" and lots of debugging. But why do you want to > play around with older versions if the latest ones work? I decided on a baseline toolset based on an old set of programs and hope to use it bring all the toolset uptodate. I didn't want to include any current versions of programs in the original toolset. > 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 21 ==========================** Date: Mon, 20 Jan 2003 20:00:36 +0000 From: John Poltorak Subject: Open Group's commands and utils Here is a list of the commands and utils which appear to be required as part of the Open Groups single Unix specification. The command name is on the left, and if there is anything to the right that is the name of a package which contains an OS/2 equivalent. We appear to be missing quite a few... If anyone knows of any OS/2 ports of those missing, can you fill them in? admin alias ar EMX asa at awk AWK basename SHU batch bc bg break c99 cal cat TU cd cflow chgrp chmod FU chown cksum TU cmp DU colon comm TU command compress GTAK continue cp FU crontab csplit TU ctags cut TU cxref date SHU dd FU delta df FU diff DU dirname SHU dot du FU echo SHU ed ED env SHU eval ex exec exit expand TU export expr SHU false SHU fc fg file FILE find FIND fold TU fort77 fuser gencat get getconf getopts grep GREP hash head TU iconv id SHU ipcrm ipcs jobs join TU kill lex FLEX link ln locale localedef logger SYSLOG logname SHU lp ls FU m4 M4 mailx make MAKE man MAN mesg mkdir FU mkfifo more mv FU newgrp nice SHU nl TU nm EMX nohup od TU paste TU patch PATCH pathchk SHU pax pr TU printf prs ps pwd SHU qalter qdel qhold qmove qmsg qrerun qrls qselect qsig qstat qsub read readonly renice return rm FU rmdel rmdir FU sact sccs sed SED set sh PDKSH shift sleep SHU sort TU split TU strings strip stty SHU tabs tail TU talk tee SHU test SHU time times touch FU tput NCURSES tr TU trap true SHU tsort TU tty SHU type ulimit umask unalias uname SHU uncompress GTAK unexpand unget uniq TU unlink unset uucp uudecode UUENCODE uuencode UUENCODE uustat uux val vi wait wc TU what who write xargs FIND yacc BYACC zcat GTAK -- John **= Email 22 ==========================** Date: Mon, 20 Jan 2003 20:18:29 +0000 From: John Poltorak Subject: Building OpenSSL Has anyone tried building OpenSSL according to the instructions here:- http://silk.apana.org.au/apache/building-openssl.html I tried but couldn't get the patch applied... Looking at OpenSSL web site there seems to be a lot of versions to choose from, and maybe the patch only works on a specific release. Which release should I download? -- John **= Email 23 ==========================** Date: Mon, 20 Jan 2003 20:20:17 +1100 (AED) From: Nicholas Sheppard Subject: Re: TERMCAP.DAT On Sun, 19 Jan 2003, John Poltorak wrote: > BTW2, Why can't we use the termcap entry for LINUX? VIO windows send different character sequences for some keys (e.g. arrows) than Linux terminals. The Linux termcap entry won't understand them. Nicholas S. |\ Location: Wollongong, Australia | Of course we lie all the time, because |\ E-mail: nps at zeta.org.au | we know that society would collapse under | WWW: http://www.zeta.org.au/~nps | the strain of relentless truth-telling. | ---> Cynicism & Negativity | - Hugh Mackay **= Email 24 ==========================** Date: Mon, 20 Jan 2003 20:50:32 +1100 (AED) From: Nicholas Sheppard Subject: Announcement: Pine 4.53 Wow! That was quick! Pine 4.53 is here, which is a bug-fix from the University of Washington. As always, more information is available from http://www.zeta.org.au/~nps/software/pine/en/index.html I've taken the opportunity to clean up some of the OS/2 bugs in npine though not as many as I might have liked. The undeleted temp files are gone, arrow keys now work in VIO windows and the /etc/passwd emulation now uses the EMX or Posix/2 header. Nicholas S. |\ Location: Wollongong, Australia | Of course we lie all the time, because |\ E-mail: nps at zeta.org.au | we know that society would collapse under | WWW: http://www.zeta.org.au/~nps | the strain of relentless truth-telling. | ---> Cynicism & Negativity | - Hugh Mackay **= Email 25 ==========================** Date: Mon, 20 Jan 2003 23:50:04 +0100 From: Thomas Hoffmann Subject: Re: Adding new file via patch You have diff let treat missing files as empty (non-missing) ones, look for the options -N --new-file Treat absent files as empty. --unidirectional-new-file Treat absent first files as empty. If you get a patch with that Only ... line, then you got an incomplete patch. Thomas. John Poltorak wrote: > How do I go about adding a new file to a distribution via a patch file? > > Normally if there is a new file, the patch file will say something like:- > > Only in .: Makefile.emx > > > Is there a way of including the missing file and getting patch to create it? > > **= Email 26 ==========================** Date: Mon, 20 Jan 2003 23:56:24 +0100 From: Thomas Hoffmann Subject: Re: Syntax of bldlevel string Yuri, thank you for the pointer, I have already downloaded this tool. But this does not exactly answer my question: What is the definition of this string or where can I find a concise description? I noted a seemingly strange handling of major/minor version numbers, e.g.. Thomas. Yuri Dario wrote: > Hi, > > >>Can anybody on the list tell something about this format? > > > in the odin source tree, under tools\bin, you can find BldLevelInf.cmd: it can build a description > string starting from option parameters. > > > Bye, > > Yuri Dario > > /* > * member of TeamOS/2 - Italy > * http://www.quasarbbs.net/yuri > * http://www.teamos2.it > * http://www.opera.com/os2/ > */ > >