From: UnixOS2 Archive To: "UnixOS2 Archive" Date: Tue, 5 Mar 2002 04:18:59 EST-10EDT,10,-1,0,7200,3,-1,0,7200,3600 Subject: [UnixOS2_Archive] No. 154 ************************************************** Monday 04 March 2002 Number 154 ************************************************** Subjects for today 1 Re: Freesco : Stepan Kazakov 2 Re: Freesco : Stepan Kazakov 3 Re: Make problem : Jack Troughton 4 IPTraf : John Poltorak 5 Re: Autoconf 2.52h : John Poltorak 6 Re: Make problem : DoC" 7 Viewing Perl POD docs : John Poltorak 8 Re: Autoconf 2.52h : Henry Sobotka 9 Autoconf 2.52i : John Poltorak 10 Make problem : John Poltorak 11 Re: Make problem : John Poltorak 12 ssh : Stefan Neis 13 Re: Autoconf 2.52h : Stefan Neis 14 Patch files : John Poltorak 15 Re: EMX port of Python... : Jeff Robinson 16 Re: M4 : Thomas Dickey 17 %UNIXROOT% : Dave and Natalie" 18 Re: Make problem : Dave and Natalie" 19 Re: Viewing Perl POD docs : Masaru Nomiya 20 Re: Autoconf 2.52h : Henry Sobotka 21 Re: Make problem : Andreas Buening 22 Re: EMX port of Python... : Andrew MacIntyre 23 Re: Autoconf 2.52h : Andrew MacIntyre 24 Re: Make problem : John Poltorak 25 M4 : John Poltorak 26 Re: Autoconf 2.52h : John Poltorak 27 Re: Autoconf 2.52h : Andreas Buening 28 Re: Autoconf 2.52h : Andreas Buening 29 Re: Make problem : lamikr **= Email 1 ==========================** Date: Tue, 05 Mar 2002 01:30:05 -0500 From: Stepan Kazakov Subject: Re: Freesco John Poltorak wrote: > > i dont know any real good network feature which is not done in OS/2 ;) > AIUI FREESCO provides Bridging and NAT... first of all we are working in this direction ;) i mean Bridging, not NAT. second: there is bridging solution in IBM product - Lan Distance (included in WS/WSeb); there are at least 3 NAT products for OS/2 : free SFF, and commerce SFL and Injoy. > I'm not talking about connecting to an external DSL modem. I thinking > about the software which runs on a DSL router. I would like to have an > OS/2 DSL router. This means having a device driver for a PCI DSL modem > card. I believe a Linux driver does exist for such a card. ok, you are talking only about drivers support. this is realy big problem in os/2, and there is no man who will write os/2 net drivers just for pleasure, in spare time... > > > > - no IPv6; > > > Will it be possible to add IPv6 support from third parties? > > yes. > That's good to hear. Is someone already working on it? i think if ipv6 will realy needed in os/2 - it could be written. > > > > - very bad sshd/2; > > > Yes, it looks as though SSHD/2 is not very usable at the moment. > > it is working.. but not so good like in unixes ;) > Which SSHD/2 are you referring to? ISTR that there are at least two. sshd version 1.2.30 [i386-pc-os2_emx] build by AndyZ or nickk. it is working, but got problems with scp :( -- madded. [Red Hot Chili Hackers] **= Email 2 ==========================** Date: Tue, 05 Mar 2002 02:47:07 -0500 From: Stepan Kazakov Subject: Re: Freesco Dave and Natalie wrote: > >second: > >there is bridging solution in IBM product - Lan Distance (included in WS/WSeb); > >there are at least 3 NAT products for OS/2 : free SFF, and commerce SFL and Injoy. > What is the free SFF? SafeFire Firewall. NAT & firewall, but only for _lan_ interfaces, not for ppp. total free. http://www.lgs.kiev.ua/ -- madded. [Red Hot Chili Hackers] **= Email 3 ==========================** Date: Tue, 05 Mar 2002 08:51:15 -0500 From: Jack Troughton Subject: Re: Make problem John Poltorak wrote: > I've just come across a strange problem when running Make (3.79.1). > When building Autoconf, I get constant error msgs popping up about > Drive E: not being ready. I'm running everything on C:, but my E: drive is > used by a PCMCIA Compact Flash card, which is not always in place. The > errors do disappear when the card is inserted, although they do not occur > if I use Make v3.76.1. > > Is there any way to identify exactly when the E: drive is being accessed? You've probably got something querying the dasd driver about the drives. When it does, dasd goes and looks at all of them, and then tells you about the one that's not ready. Do you have autofail=yes in your config.sys? If yes, then I'd be concerned and dig deeper, but if not, try putting it in there and see if they go away or not. By default, OS/2 will tell you about stuff like that, even though you "know" there's nothing in the removable media anyway... autofail turns down the volume on the state reporting. Regards, Jack -- ------------------------------------------------------------------- * Jack Troughton jake at jakesplace.dhs.org * * http://jakesplace.dhs.org ftp://jakesplace.dhs.org * * MontrÚal PQ Canada news://jakesplace.dhs.org * ------------------------------------------------------------------- **= Email 4 ==========================** Date: Tue, 5 Mar 2002 09:02:08 +0000 From: John Poltorak Subject: IPTraf IPTraf is a console-based network statistics utility for Linux. It gathers a variety of figures such as TCP connection packet and byte counts, interface statistics and activity indicators, TCP/UDP traffic breakdowns, and LAN station packet and byte counts. See:- http://cebu.mozcom.com/riker/iptraf/ Has anyone used this app? It sounds like something I'd like to be able to use. Wonder if it will port to OS/2.... -- John **= Email 5 ==========================** Date: Tue, 5 Mar 2002 09:49:06 +0000 From: John Poltorak Subject: Re: Autoconf 2.52h On Mon, Mar 04, 2002 at 07:16:54PM -0500, Henry Sobotka wrote: > John Poltorak wrote: > > > > > > > f) notes: you need a /emx/lib/db.lib that works with -Zmt > > > > does result in fewer test failures. What I'd like to know is what do I > > change in emx to create this file... It must be something under emx\bsd\db > > but I can't figure out what... > > Build with -Zmt? Should this be included on the 'CC=' line of emx\bsd\db\emx\makefile.sub? > > I think the building of Perl is a good test for having the correct build > > environment, > > No, Perl has a unique build system and requires a specific shell. > Building it just proves that you have a healthy environment to build > Perl, not that you're set up for a mainstream configure-make build. It's > too eccentric to use as a standard. OK, maybe 'correct' is the wrong word, but being able to build Perl is an indication of having, as you say, a healthy environment. > Stringing a selection of AC* macros > together in a configure.in and running that to check the setup might > make for a more suitable test; since the macros are there and a cinch to > work with, why not use them? Care to amplify? It would be great to have a build environment checker, but I can't think of the best way of doing it. > > I'd like to document a procedure which ought to create a specific build, > > What's wrong with Ilya's detailed instructions in the OS/2 section of > the Perl docs? Well, detailed instructions are not the same as a build script. They can easily be misinterpreted or make assumptions which are not valid. > Any two people who follow them to the letter, have the > same source, matching toolkits, and go with the default values, i.e. > don't edit config.sh, should get identical results. Maybe they should but they don't. I recently compared my results against yours and found a large number of differences. AFAIAA I followed the instructions as best I could. I used the same source and the only change I made to the defaults was the value of PREFIX. However, the main difference is probably due to toolkits. Until a standard toolkit is defined and accepted, we are bound to have differences. > h~ -- John **= Email 6 ==========================** Date: Tue, 05 Mar 2002 10:01:50 -0300 (EST) From: "DoC" Subject: Re: Make problem On Tue, 5 Mar 2002 11:50:07 +0000, John Poltorak wrote: > >I've just come across a strange problem when running Make (3.79.1). >When building Autoconf, I get constant error msgs popping up about >Drive E: not being ready. I'm running everything on C:, but my E: drive is >used by a PCMCIA Compact Flash card, which is not always in place. The >errors do disappear when the card is inserted, although they do not occur >if I use Make v3.76.1. > > >Is there any way to identify exactly when the E: drive is being accessed? > Probably some part of it is checking all available drives. Have you considered using AUTOFAIL=YES in CONFIG.SYS? That would eliminate all the silly "drive not ready" messages. -- DoC **= Email 7 ==========================** Date: Tue, 5 Mar 2002 10:11:50 +0000 From: John Poltorak Subject: Viewing Perl POD docs What should I use to view Perl POD files? -- John **= Email 8 ==========================** Date: Tue, 05 Mar 2002 11:21:25 -0500 From: Henry Sobotka Subject: Re: Autoconf 2.52h John Poltorak wrote: > > > Build with -Zmt? > > Should this be included on the 'CC=' line of emx\bsd\db\emx\makefile.sub? Yes. > OK, maybe 'correct' is the wrong word, but being able to build Perl is an > indication of having, as you say, a healthy environment. Again, for building Perl. Sure, the Perl build uses many of the standard tools, but it's an exceptional system with all kinds of OS/2- and EMX-specific tweaks. Just about any mainstream GNU package that uses the routine configure-make system would be a more reliable indicator. > > Stringing a selection of AC* macros > > together in a configure.in and running that to check the setup might > > make for a more suitable test; since the macros are there and a cinch to > > work with, why not use them? > > Care to amplify? Instead of writing an elaborate shell script, create a configure.in containing, for example: AC_INIT AC_PROG_CPP AC_PROG_CXXCPP AC_PROG_AWK AC_PATH_PROGS(EMACS, xemacs lemacs emacs, :) AC_PATH_PROGS(PERL, $PERL perl5 perl ) AC_PATH_PROG(WHOAMI, whoami, :) AC_PATH_PROG(AUTOCONF, autoconf, :) AC_PATH_PROG(UNZIP, unzip, :) AC_PATH_PROGS(ZIP, zip) AC_CHECK_LIB(cposix,strerror) Feed it to autoconf to create configure, snip out the block of substitutions at the end, and rename it "check-unixos2" or whatever. You've got a ~1250-line script that runs those particular tests. My point is simply that the above 11 macros are easy to write and make exactly what we're checking for.clear at a glance. There are all kinds of other macros available (e.g. AC_TRY_COMPILE) and obviously this should be done properly by someone more familiar with the full range of macros. > > > I'd like to document a procedure which ought to create a specific build, > > > > What's wrong with Ilya's detailed instructions in the OS/2 section of > > the Perl docs? > > Well, detailed instructions are not the same as a build script. They can > easily be misinterpreted or make assumptions which are not valid. I took "document a procedure..." to mean write a how-to-build doc. A script is a whole other ballgame. > > Any two people who follow them to the letter, have the > > same source, matching toolkits, and go with the default values, i.e. > > don't edit config.sh, should get identical results. > > Maybe they should but they don't. I recently compared my results against > yours and found a large number of differences. AFAIAA I followed the > instructions as best I could. I used the same source and the only change I > made to the defaults was the value of PREFIX. However, the main difference > is probably due to toolkits. Until a standard toolkit is defined and > accepted, we are bound to have differences. But I hadn't built with the defaults; I went through config.sh line by line, making all kinds of adjustments before building. Yet the first times I built Perl a few years ago with zero tweaks I remember getting test results identical to those Ilya discusses in the doc. h~ **= Email 9 ==========================** Date: Tue, 5 Mar 2002 11:34:35 +0000 From: John Poltorak Subject: Autoconf 2.52i Autoconf v2.52i has been released as is available from:- ftp://alpha.gnu.org/gnu/autoconf/autoconf-2.52i.tar.gz This is being seen as the release candidate for v2.53 which should follow on fairly soon. If anyone does use Autoconf, please give this a try and report any problems to the Autoconf maintainers. It would be nice to get an OS/2 friendly version out without having to maintain a seperate port. -- John **= Email 10 ==========================** Date: Tue, 5 Mar 2002 11:50:07 +0000 From: John Poltorak Subject: Make problem I've just come across a strange problem when running Make (3.79.1). When building Autoconf, I get constant error msgs popping up about Drive E: not being ready. I'm running everything on C:, but my E: drive is used by a PCMCIA Compact Flash card, which is not always in place. The errors do disappear when the card is inserted, although they do not occur if I use Make v3.76.1. Is there any way to identify exactly when the E: drive is being accessed? -- John **= Email 11 ==========================** Date: Tue, 5 Mar 2002 14:26:24 +0000 From: John Poltorak Subject: Re: Make problem On Tue, Mar 05, 2002 at 08:51:15AM -0500, Jack Troughton wrote: > John Poltorak wrote: > > I've just come across a strange problem when running Make (3.79.1). > > When building Autoconf, I get constant error msgs popping up about > > Drive E: not being ready. I'm running everything on C:, but my E: drive is > > used by a PCMCIA Compact Flash card, which is not always in place. The > > errors do disappear when the card is inserted, although they do not occur > > if I use Make v3.76.1. > > > > Is there any way to identify exactly when the E: drive is being accessed? > > You've probably got something querying the dasd driver about the drives. > When it does, dasd goes and looks at all of them, and then tells you > about the one that's not ready. My point was that this is new behaviour introduced in Make 3.79.1 and I was trying to identify the code which causes it. > > Do you have autofail=yes in your config.sys? If yes, then I'd be > concerned and dig deeper, but if not, try putting it in there and see if > they go away or not. By default, OS/2 will tell you about stuff like > that, even though you "know" there's nothing in the removable media > anyway... autofail turns down the volume on the state reporting. As it happens, I do not have Autofail set on this particular system, but have noticed that no such msg occurs regarding the unavailabilty of F: which is also allocated by the PCMCIA drivers, but not in use, irrespective of the accessibilty of E: > > Regards, > > Jack > > > > -- > ------------------------------------------------------------------- > * Jack Troughton jake at jakesplace.dhs.org * > * http://jakesplace.dhs.org ftp://jakesplace.dhs.org * > * MontrÚal PQ Canada news://jakesplace.dhs.org * > ------------------------------------------------------------------- > -- John **= Email 12 ==========================** Date: Tue, 5 Mar 2002 15:03:57 +0100 (CET) From: Stefan Neis Subject: ssh On Tue, 5 Mar 2002, Stepan Kazakov wrote: > > > > > - very bad sshd/2; > > > > Yes, it looks as though SSHD/2 is not very usable at the moment. > > > it is working.. but not so good like in unixes ;) > > Which SSHD/2 are you referring to? ISTR that there are at least two. > > sshd version 1.2.30 [i386-pc-os2_emx] > build by AndyZ or nickk. > it is working, but got problems with scp :( I "solved" that problem (for me) by just copying the scp from openssh-port over the one provided within "sshd version 1.2.30". Everything _seems_ to be working right now. I suppose I really should update to openssh-port, but I have problems with setting it up reasonably... Regards, Stefan -- Micro$oft is not an answer. It is a question. The answer is 'no'. **= Email 13 ==========================** Date: Tue, 5 Mar 2002 15:21:41 +0100 (CET) From: Stefan Neis Subject: Re: Autoconf 2.52h On Mon, 4 Mar 2002, John Poltorak wrote: > > As Stefan already mentioned: .PHONY: install > > How do I incorporate this into a build script? Try to convince maintainers to add it to Makefile or Makefile.in or whatever they use - as I said it shouldn't do any harm on other platforms and might be even helpful as currently it's easy to confuse the build process on all platforms by a simple "touch install". Otherwise the following might help: echo .PHONY: install > tmpfile cat tmpfile Makefile > Makefile.new mv Makefile.new Makefile (DUAU, i.e.: Disclaimer: untested - as usual) Not the most elegant location for the additional line, but it should work. > Using a threaded version of db.lib as found here:- > > http://www.math.ohio-state.edu/~ilya/software/os2/db_mt.zip You're sure it isn't using a newer version of the source code anyway? > I think the building of Perl is a good test for having the correct build > environment, ... for building perl. Other packages might have other preferences. E.g. even if perl is working best with - maybe - pdksh for sh.exe, all standard autoconf-configure-make software might prefer a different shell. Regards, Stefan -- Micro$oft is not an answer. It is a question. The answer is 'no'. **= Email 14 ==========================** Date: Tue, 5 Mar 2002 16:08:37 +0000 From: John Poltorak Subject: Patch files I'm trying to amend some patch files from different apps so that they have the same number of leading components in filenames, ie. I would like to be able to use the same -p value for all diffs. Is there any utility avaiable which will remove superfluous directory levels from patches ? -- John **= Email 15 ==========================** Date: Tue, 05 Mar 2002 16:40:36 -0600 From: Jeff Robinson Subject: Re: EMX port of Python... Andrew MacIntyre wrote: > > On Mon, 4 Mar 2002, John Poltorak wrote: > > > On Mon, Mar 04, 2002 at 07:43:11PM +1100, Andrew MacIntyre wrote: > > > has now been integrated into Python CVS, and will be maintained there. > > > > Does that mean it can be built and installed using autoconf, configure and > > Make? > > Why use autoconf and configure when the port build directory supplies a > perfectly good pyconfig.h and Makefile? I don't plan to try and sort out > the autoconf/configure mess^H^H^H^Hprocess myself, but patches would be > considered. > > The optional modules are not enabled by default because all the widely > available packages involved either aren't part of EMX or require > patches/recompilation (or both!). > Does this mean that (soon) I will be able to just grab the source distribution of Python and build it myself... thus having the proper pre-makefile that is required to build Zope...? Oooh... dare I dream? Jeff -- ---------------- Whatza JamochaMUD? http://jamochamud.anecho.mb.ca Or other stuff: http://www.anecho.mb.ca/~jeffnik ----------------------------------------------------------- **= Email 16 ==========================** Date: Tue, 5 Mar 2002 17:34:49 -0500 From: Thomas Dickey Subject: Re: M4 On Tue, Mar 05, 2002 at 09:47:52PM +0000, John Poltorak wrote: > I suspect this is because some patches were designed to get round > shortcomings in a previous version of Autoconf and may no longer be not exactly. those warnings are glossing some of the known places where autoconf 2.5x is incompatible with 2.13 (it's possible to design configure scripts which are compatible between the two versions, but apparently the autoconf maintainers are more interested in getting people to use 2.5x than making its messages correct). -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net **= Email 17 ==========================** Date: Tue, 05 Mar 2002 18:53:36 +0000 From: "Dave and Natalie" Subject: %UNIXROOT% So how do you get a program to use %UNIXROOT%. Is it as simple as --prefix=$UNIXROOT/usr or do you have to hack the code? If so could I see an example Also what happens if %UNIXROOT% isn't defined? Dave **= Email 18 ==========================** Date: Tue, 05 Mar 2002 18:53:49 +0000 From: "Dave and Natalie" Subject: Re: Make problem On Wed, 06 Mar 2002 00:34:01 +0100, Andreas Buening wrote: >However, to avoid thing like "Drive x: not ready" >binaries should be built for "c:". This seems strange, I think that most OS/2 users keep a win partition around which is C:. Why not just build for /. I always use --prefix=/usr and haven't had any problems. Sometimes I'm using F:, my main data partition which has a Unix file system on it and sometimes I use X: which is a TVFS volume also with a Unix filesystem. Everything else is referenced by %PATH% or enviroment variables. EMX is on E: With HD price/Gb ratio I think most all users should be able to have a large enough partition to have their *nix file system. Of course %UNIXROOT% is also a good solution. Dave **= Email 19 ==========================** Date: Tue, 05 Mar 2002 19:34:21 +0900 From: Masaru Nomiya Subject: Re: Viewing Perl POD docs Hello, In the Message; Subject : Viewing Perl POD docs Message-ID : <20020305101149.T92 at eyup.org> Date & Time: Tue, 5 Mar 2002 10:11:50 +0000 [John] == John Poltorak has written: John> What should I use to view Perl POD files? I use perldoc.cmd which I made this by inserting extproc perl.exe -Sx at the top line of the perldoc, and save as perldoc.cmd. Regards, --- Masaru Nomiya mail-to: nomiya at ttmy.ne.jp "No WIndows, no gains!" ..... "Why, I am wrong?" -- Bill -- **= Email 20 ==========================** Date: Tue, 05 Mar 2002 20:06:26 -0500 From: Henry Sobotka Subject: Re: Autoconf 2.52h Andreas Buening wrote: > > No, it's not. It's extremely fragile. If you change a period > it will fail. If I stick my hand into my car's engine and yank a wire or hose loose, it too might fail, but that doesn't make it fragile machinery. By your criterion, one could equally say that C is a fragile language because a program can fail due to writing "=" instead of "==", or that gcc is a fragile compiler because a trivial typo in the code can cause it to spew voluminously and bail. > It might be that everything is > mentioned in the README.os2 file, but I really doubt. Actually the Perl documentation includes a lengthy OS/2 section, where you'll find detailed build instructions starting with toolkit requirements and ending with test results and common problems. Follow them carefully and it's a cakewalk. > Nevertheless, according to my current perl > experience the perl build mechanism is more vi, which means > it's in the middle of evil. ;-) The Perl build system is not of the autoconf-automake genre, and I'm inclined to doubt Makefile.am's will ever replace Makefile.PL's. To consider it evil because it's different is like calling apples a bane because they don't peel the way oranges do. Complex projects often have special requirements. Mozilla expects "gbash" and "gmake" (literally). Building gcc you get into trouble by running "make" instead of "make bootstrap", or not doing it from a directory outside the src tree. Perl also has the distinction of being a programming language and interpreter as opposed to "yet another" GNU utility. From my experience, that makes it all the more likely to have its own build system best taken on its own terms. h~ **= Email 21 ==========================** Date: Tue, 05 Mar 2002 20:13:34 +0100 From: Andreas Buening Subject: Re: Make problem John Poltorak wrote: > > On Tue, Mar 05, 2002 at 08:51:15AM -0500, Jack Troughton wrote: > > John Poltorak wrote: > > > I've just come across a strange problem when running Make (3.79.1). > > > When building Autoconf, I get constant error msgs popping up about > > > Drive E: not being ready. I'm running everything on C:, but my E: drive is > > > used by a PCMCIA Compact Flash card, which is not always in place. The > > > errors do disappear when the card is inserted, although they do not occur > > > if I use Make v3.76.1. > > > > > > Is there any way to identify exactly when the E: drive is being accessed? > > > > You've probably got something querying the dasd driver about the drives. > > When it does, dasd goes and looks at all of them, and then tells you > > about the one that's not ready. > > My point was that this is new behaviour introduced in Make 3.79.1 and I > was trying to identify the code which causes it. [snip] Oops. This thread is really very impressing, but it's quite simple: When I uploaded the last make binary I didn't make a complete build but simply copied the file from my build tree (e:/usr/bin). That's all. Normally I build binaries for c:/usr. Sorry for that inconvenience. 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 Redmond where the Shadows lie. **= Email 22 ==========================** Date: Tue, 5 Mar 2002 20:34:44 +1100 (EDT) From: Andrew MacIntyre Subject: Re: EMX port of Python... On Mon, 4 Mar 2002, John Poltorak wrote: > On Mon, Mar 04, 2002 at 07:43:11PM +1100, Andrew MacIntyre wrote: > > has now been integrated into Python CVS, and will be maintained there. > > Does that mean it can be built and installed using autoconf, configure and > Make? Why use autoconf and configure when the port build directory supplies a perfectly good pyconfig.h and Makefile? I don't plan to try and sort out the autoconf/configure mess^H^H^H^Hprocess myself, but patches would be considered. The optional modules are not enabled by default because all the widely available packages involved either aren't part of EMX or require patches/recompilation (or both!). -- 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 **= Email 23 ==========================** Date: Tue, 5 Mar 2002 20:40:19 +1100 (EDT) From: Andrew MacIntyre Subject: Re: Autoconf 2.52h On Mon, 4 Mar 2002, John Poltorak wrote: > Using a threaded version of db.lib as found here:- > > http://www.math.ohio-state.edu/~ilya/software/os2/db_mt.zip > > does result in fewer test failures. What I'd like to know is what do I > change in emx to create this file... It must be something under emx\bsd\db > but I can't figure out what... The Python source patches archives I have released (on Hobbes or my Python pages) have the necessary patches to fix this. -- 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 **= Email 24 ==========================** Date: Tue, 5 Mar 2002 21:36:35 +0000 From: John Poltorak Subject: Re: Make problem On Tue, Mar 05, 2002 at 08:13:34PM +0100, Andreas Buening wrote: > John Poltorak wrote: > > > > > > Is there any way to identify exactly when the E: drive is being accessed? > > > > > > You've probably got something querying the dasd driver about the drives. > > > When it does, dasd goes and looks at all of them, and then tells you > > > about the one that's not ready. > > > > My point was that this is new behaviour introduced in Make 3.79.1 and I > > was trying to identify the code which causes it. > > [snip] > > Oops. This thread is really very impressing, but it's > quite simple: When I uploaded the last make binary > I didn't make a complete build but simply copied the file > from my build tree (e:/usr/bin). That's all. Normally > I build binaries for c:/usr. > Sorry for that inconvenience. That's OK - I'm glad it was something simple. It makes me think that it is probably better to build apps directly on the target system rather than simplying installing them with hard-coded paths which are not relevant.... One idea I had was to include some sort of patching of hard-coded paths as part of the install process so that c: would be changed to the value of %UNIXROOT% by the installer. Does anyone foresee any problems in doing something like that? > 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 Redmond where the Shadows lie. -- John **= Email 25 ==========================** Date: Tue, 5 Mar 2002 21:47:52 +0000 From: John Poltorak Subject: M4 I just tried building M4 using Autoconf v2.52i after applying the recent OS/2 patches and it worked fine, although I did get a few warnings:- WARNING: Using auxiliary files such as `acconfig.h', `config.h.bot' WARNING: and `config.h.top', to define templates for `config.h.in' WARNING: is deprecated and discouraged. WARNING: Using the third argument of `AC_DEFINE' and WARNING: `AC_DEFINE_UNQUOTED' allows to define a template without WARNING: `acconfig.h': WARNING: AC_DEFINE([NEED_MAIN], 1, WARNING: [Define if a function `main' is needed.]) WARNING: More sophisticated templates can also be produced, see the WARNING: documentation. autoheader: `config.h.in' is updated date > ./stamp-h.in I suspect this is because some patches were designed to get round shortcomings in a previous version of Autoconf and may no longer be required. Is there anything which can now be removed from the diffs in the M4 port? -- John **= Email 26 ==========================** Date: Tue, 5 Mar 2002 21:55:06 +0000 From: John Poltorak Subject: Re: Autoconf 2.52h On Tue, Mar 05, 2002 at 09:58:42PM +0100, Andreas Buening wrote: > Stefan Neis wrote: > > > > On Mon, 4 Mar 2002, John Poltorak wrote: > > [.PHONY: install] > > > > I think the building of Perl is a good test for having the correct build > > > environment, > > > > ... for building perl. Other packages might have other preferences. > > E.g. even if perl is working best with - maybe - pdksh for sh.exe, all > > standard autoconf-configure-make software might prefer a different shell. > > And exactly this misbehaviour must really be removed. > I've never heard of a Unix user who had to things like > > rm /bin/sh > cp -p /usr/local/bin/ksh /bin/sh > > to get one specific software package installed. This really is a crazy situation, but I don't know a solution to it. BTW PDKSH includes sh.exe as well as ksh.exe. I always use sh.exe, but have no idea what difference is between them... > 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 Redmond where the Shadows lie. -- John **= Email 27 ==========================** Date: Tue, 05 Mar 2002 21:58:42 +0100 From: Andreas Buening Subject: Re: Autoconf 2.52h Stefan Neis wrote: > > On Mon, 4 Mar 2002, John Poltorak wrote: [.PHONY: install] > > I think the building of Perl is a good test for having the correct build > > environment, > > ... for building perl. Other packages might have other preferences. > E.g. even if perl is working best with - maybe - pdksh for sh.exe, all > standard autoconf-configure-make software might prefer a different shell. And exactly this misbehaviour must really be removed. I've never heard of a Unix user who had to things like rm /bin/sh cp -p /usr/local/bin/ksh /bin/sh to get one specific software package installed. 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 Redmond where the Shadows lie. **= Email 28 ==========================** Date: Tue, 05 Mar 2002 21:58:52 +0100 From: Andreas Buening Subject: Re: Autoconf 2.52h Henry Sobotka wrote: > > Andreas Buening wrote: > > > > The more important problem are the very fragile compilation > > process and the hardcoded paths. perl should be able to find > > its shell and libs and whatever might be hardcoded in > > $UNIXROOT/usr/... without any further env. vars. > > Then we won't need 24 different binary distributions of perl, > > one for every possible drive letter. :-))) > > The Perl build system could be called Celtic or even Byzantine in > design, but is quite solid if you carefully follow Ilya's instructions. > Given its ability to handle the various flavors of perl*.exe for OS/2, > CPAN modules involving DLLs, as well as new extensions, I would qualify > it as delightfully robust. No, it's not. It's extremely fragile. I you change a period it will fail. - It uses normal upper case env. vars. for internal purpose (autoconf e.g. uses $ac_* names which are quite safe because of that prefix) - I relies on a specific shell to be in /bin and $PATH - You cannot compile perl if you use the wrong _interactive_ (!!!) shell Let's assume you want to compile perl, it fails and you're searching for the reason. You might suspect the shell is the reason. If it's only /bin/sh and the first shell in your PATH it's about 9 combinations of bash, ash and ksh you can try. If you take EMXSHELL into account, it's 27. Perhaps it's because pgcc 2.95 fails and gcc 2.8.1 would work? Now it's 54. Perhaps it's make? There are a lot of builds of make. Now you have more than 100 possible combinations. Perhaps it's because you had set some CFLAGS, GCCOPT that are not compatible? Because your C_INCLUDE_PATH, LIBRARY_PATH is too long? Because you haven't applied the latest emx fix? Because OS/2's sort is in front of your path and not GNU sort? Is some variable missing? Perhaps a typo in config.sys? What about $SHELL? Or have you installed the correct version of those GNU tools? A lot of them are quite old, perhaps too old? Perhaps the current version doesn't work? Try an Older one? You can easily waste a week of your spare time to test dozens of configurations without getting perl compiled. These 100 possible combinations of things that could be wrong will drive you nuts. And that makes the build mechanism as fragile as it can be. It might be that erverything is mentioned in the README.os2 file, but I really doubt. Sure, autoconf and other build mechanism also aren't as stable as they should be, we don't need to discuss that topic. Nevertheless, according to my current perl experience the perl build mechanism is more vi, which means it's in the middle of evil. ;-) [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 Redmond where the Shadows lie. **= Email 29 ==========================** Date: Tue, 05 Mar 2002 23:27:23 +0100 From: lamikr Subject: Re: Make problem What is causing this the drive-letter based hardcoding? (I am have my OS/2 build systems in f:\unixos2\usr...) Mika Andreas Buening wrote: > John Poltorak wrote: > > > > On Tue, Mar 05, 2002 at 08:51:15AM -0500, Jack Troughton wrote: > > > John Poltorak wrote: > > > > I've just come across a strange problem when running Make (3.79.1). > > > > When building Autoconf, I get constant error msgs popping up about > > > > Drive E: not being ready. I'm running everything on C:, but my E: drive is > > > > used by a PCMCIA Compact Flash card, which is not always in place. The > > > > errors do disappear when the card is inserted, although they do not occur > > > > if I use Make v3.76.1. > > > > > > > > Is there any way to identify exactly when the E: drive is being accessed? > > > > > > You've probably got something querying the dasd driver about the drives. > > > When it does, dasd goes and looks at all of them, and then tells you > > > about the one that's not ready. > > > > My point was that this is new behaviour introduced in Make 3.79.1 and I > > was trying to identify the code which causes it. > > [snip] > > Oops. This thread is really very impressing, but it's > quite simple: When I uploaded the last make binary > I didn't make a complete build but simply copied the file > from my build tree (e:/usr/bin). That's all. Normally > I build binaries for c:/usr. > Sorry for that inconvenience. > > 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 Redmond where the Shadows lie.