From: UnixOS2 Archive To: "UnixOS2 Archive" Date: Thu, 20 Jun 2002 04:28:02 EST-10EDT,10,-1,0,7200,3,-1,0,7200,3600 Subject: [UnixOS2_Archive] No. 248 ************************************************** Wednesday 19 June 2002 Number 248 ************************************************** Subjects for today 1 Re: Make v3.79.1 & Emacs : Masaru Nomiya 2 Re: Make v3.79.1 & Emacs : Masaru Nomiya 3 Sendmail 8.12.3 : IanM" 4 Re: Can't make automake : John Poltorak 5 OpenSSH & /usr/libexec : Adrian Gschwend" 6 Re: OpenSSH & /usr/libexec : Holger Veit 7 Re: OpenSSH & /usr/libexec : Adrian Gschwend" 8 Re: Re: Perl 5.8.0 - no progress : John Poltorak 9 Re: Mozilla collision with XFree86/OS2 : Henry Sobotka 10 unixos2 packages : Adrian Gschwend" 11 Re: Mozilla collision with XFree86/OS2 : Jack Troughton 12 Re: unixos2 packages : John Poltorak 13 Mozilla collision with XFree86/OS2 : Lyn St George" 14 Re: Mozilla collision with XFree86/OS2 : Lyn St George" 15 Re: unixos2 packages : nick" 16 Re: Re: Make v3.79.1 & Emacs : Masaru Nomiya 17 Re: Perl 5.8.0 - no progress : Masaru Nomiya **= Email 1 ==========================** Date: Thu, 20 Jun 2002 00:22:49 +0900 From: Masaru Nomiya Subject: Re: Make v3.79.1 & Emacs Hello, In the Message; Subject : Re: Re: Make v3.79.1 & Emacs Message-ID : <20020619155832.L91 at eyup.org> Date & Time: Wed, 19 Jun 2002 15:58:32 +0100 [John] == John Poltorak has written: John> I have always used the tar.exe from GTAR258. Me> Me, too! Me> But, in some cases, diskacc,dll be required (This is well known among Me> Japanese OS/2 + emx/gcc users). John> Is this related to DBCS? No. Me> GNUTAR.ZIP; Me> 96-08-19 7:29 217709 0 GNUTAR.ZIP John> Where do I find it, it isn't on Hobbes. Really! I have a look on LEO, too. There doesn't exist. What's the matter. I wonder? BTW, I'll send you. Me> By this, install diskacc.dll, then try 'tar zxf Me> emacs-20.7-KIT1,9.tgz'. John> The tar.exe in GTAR258 does not know anything about diskacc.dll, AFAICT, John> does this mean I need two sperate copies of tar? I'm sorry, but you need to install diskacc,dll only. Regards, --- Masaru Nomiya mail-to: nomiya at ttmy.ne.jp "No Windows, no gains!" ..... "Why, I am wrong?" -- Bill -- **= Email 2 ==========================** Date: Thu, 20 Jun 2002 00:35:12 +0900 From: Masaru Nomiya Subject: Re: Make v3.79.1 & Emacs Hello, In the Message; Subject : Re: Make v3.79.1 & Emacs Message-ID : Date & Time: Thu, 20 Jun 2002 00:22:49 +0900 [Me] == Masaru Nomiya has written: Me> GNUTAR.ZIP; Me> 96-08-19 7:29 217709 0 GNUTAR.ZIP John> Where do I find it, it isn't on Hobbes. Me> Really! Me> I have a look on LEO, too. Me> There doesn't exist. No, there exists here; ftp://ftp.leo.org/pub/comp/os/dos/gnuish/gnutar.zip Regards, --- Masaru Nomiya mail-to: nomiya at ttmy.ne.jp "No Windows, no gains!" ..... "Why, I am wrong?" -- Bill -- **= Email 3 ==========================** Date: Thu, 20 Jun 2002 04:58:55 +1000 (EST) From: "IanM" Subject: Sendmail 8.12.3 **= Email 4 ==========================** Date: Thu, 20 Jun 2002 10:18:30 +0100 From: John Poltorak Subject: Re: Can't make automake On Wed, Jun 19, 2002 at 07:51:00PM -0500, paul-biz wrote: > When I try to configure automake 1.6.2 or 1.5, it tells me I don't have > perl installed (I do). If i type 'which perl' immediately after the > error, it tells me where my perl is (d:\emx\bin\perl.exe). I don't know > what I'm doing wrong... It's perl 5.004_55. Anybody else have any > better luck? Do you get something like this? :- [C:\eval\automake\automake-1.6.2]sh configure configure.: creating cache /dev/null checking for a BSD-compatible install... lib/install-sh -c checking whether build environment is sane... yes checking for gawk... no checking for mawk... no checking for nawk... no checking for awk... no checking whether make sets ${MAKE}... yes checking for perl... no configure.: error: perl not found I suspect you need to rebuild configure, using autoconf... This is what I get eventually:- ./configure configure: loading site script c:/unixos2/lib/config.site configure: creating cache /dev/null checking for a BSD-compatible install... c:/usr/bin/install.exe -c checking whether build environment is sane... yes checking for gawk... awk checking whether make sets ${MAKE}... yes checking for perl... c:/usr/bin/perl.exe not updating unwritable cache /dev/null configure: creating ./config.status config.status: creating automake config.status: creating aclocal config.status: creating Makefile config.status: creating lib/Automake/Makefile config.status: creating lib/Makefile config.status: creating lib/am/Makefile config.status: creating m4/Makefile config.status: creating m4/amversion.m4 config.status: creating tests/Makefile Making all in . I've just tried to build it using my standard build framework and it appears to have worked perfectly, which is great. This framework is something I'm developing to be able to handle every app I can throw at it. In theory everything should build using:- build APPNAME There's a long way to go, but it's a start. Libtool is probably something I need to incorporate into it at some point if I want it to cope with DLLs. > Thanks, > Paul -- John **= Email 5 ==========================** Date: Thu, 20 Jun 2002 11:28:23 +0200 (CDT) From: "Adrian Gschwend" Subject: OpenSSH & /usr/libexec Hi all, I'm in progress of building an unixos2 package for the excellent OpenSSH port from nickk. It's not that hard to do but there is one open question: It looks like some of the binaries in the original install are put to /usr/libexec, I looked for the reason and found none :-) But on one page I found this statement: --libexecdir=/usr/sbin : OpenSSH puts programs called by programs in /usr/libexec. sftp-server is a sshd utility and ssh-askpass is a ssh-add utility that is installed as a link to X11-ssh-askpass. Both of these should go in /usr/sbin not /usr/libexec. so it looks like some distros put it into /usr/sbin because /usr/libexec seems not to be FHS compatible. What's the recommended way to go on OS/2, /usr/sbin as well? cu Adrian -- Adrian Gschwend at OS/2 Netlabs ICQ: 22419590 ktk at netlabs.org ------- The OS/2 OpenSource Project: http://www.netlabs.org **= Email 6 ==========================** Date: Thu, 20 Jun 2002 11:54:01 +0200 From: Holger Veit Subject: Re: OpenSSH & /usr/libexec On Thu, Jun 20, 2002 at 11:28:23AM +0200, Adrian Gschwend wrote: > Hi all, > > I'm in progress of building an unixos2 package for the excellent > OpenSSH port from nickk. It's not that hard to do but there is one open > question: It looks like some of the binaries in the original install > are put to /usr/libexec, I looked for the reason and found none :-) But > on one page I found this statement: > > > --libexecdir=/usr/sbin : OpenSSH puts programs called by programs in > /usr/libexec. sftp-server is a sshd utility and ssh-askpass is a > ssh-add utility that is installed as a link to X11-ssh-askpass. Both of > these should go in /usr/sbin not /usr/libexec. > > so it looks like some distros put it into /usr/sbin because > /usr/libexec seems not to be FHS compatible. > > What's the recommended way to go on OS/2, /usr/sbin as well? Hmmmm.... /usr/libexec is a BSDism. Effectively, various BSD executables would go there if you were to compile sources from e.g. 4.4BSD. Personally, although with libemu inheriting heavily from BSD, /usr/sbin (in relation to /sbin) looks *nowadays* more consequent (BSD has /sbin and /usr/libexec). Traditionally, /sbin was the directory of *statically* linked binaries, to be usable for system recovery when shared libs were not present, and /usr/sbin were an extension to this. Over time, the *s* mutated into *system*, so /usr/sbin has become home of system executables. /usr/libexec was BSDs attempt to move helper executables which were originally in /usr/lib out of the library directory and just keep real libraries there. Those executables were not for direct call by users, so they would be not correctly located in /usr/bin, leading to /usr/libexec invention. Nowadays, /usr/sbin is *system* executables (not for Joe average), so OpenSSH should rather go to /usr/sbin than some obscure /usr/libexec. Holger -- Please update your tables to my new e-mail address: holger.veit$ais.fhg.de (replace the '$' with ' at ' -- spam-protection) **= Email 7 ==========================** Date: Thu, 20 Jun 2002 12:44:44 +0200 (CDT) From: "Adrian Gschwend" Subject: Re: OpenSSH & /usr/libexec On Thu, 20 Jun 2002 11:54:01 +0200, Holger Veit wrote: >there. Those executables were not for direct call by users, so they would >be not correctly located in /usr/bin, leading to /usr/libexec invention. >Nowadays, /usr/sbin is *system* executables (not for Joe average), >so OpenSSH should rather go to /usr/sbin than some obscure >/usr/libexec. thanks a lot, will go that way then! cu Adrian -- Adrian Gschwend at OS/2 Netlabs ICQ: 22419590 ktk at netlabs.org ------- The OS/2 OpenSource Project: http://www.netlabs.org **= Email 8 ==========================** Date: Thu, 20 Jun 2002 15:25:50 +0100 From: John Poltorak Subject: Re: Re: Perl 5.8.0 - no progress On Thu, Jun 20, 2002 at 10:36:38PM +0900, Masaru Nomiya wrote: > Stefan> Not really. The bad test is relying on an environment variable > Stefan> which normally doesn't exist on OS/2 (LIBPATH), but if you set > Stefan> that variable to the "correct" value that bogus test will succeed. > Stefan> And if your LIBPATH (the real one, not the useless environment > Stefan> variable with the same name) contains the required DLLs as well, > Stefan> the rest will work, too. > > Thanks, I could understand. > > In the statement; > > use OS2::REXX; > > $name = "VREXX"; > $path = $ENV{LIBPATH} || $ENV{PATH} or die; > foreach $dir (split(';', $path)) { > next unless -f "$dir/$name.DLL"; > $found = "$dir/$name.DLL"; > print "# found at `$found'\n"; > last; > } > ... > > > $ENV{LIBPATH} is different from LIBPATH in CONFIG.SYS. > > I think, $ENV{LIBPATH} should be changed the one which would be read > from CONFIG.SYS. > > But, how.... LIBPATH does not exist in the environment, so this is a completely bogus test. IMV the test should try to load the DLL to see if it exists, but I have no idea how this could be done. I guess the other alternative is to put the DLLs on the path... Under UnixOS/2, it has been suggested that DLLs go into /usr/lib, which is where LIBRARY_PATH would point, so maybe $ENV{LIBRARY_PATH} should be used... Should we be including VREXX and RXU in UnixOS/2, BTW? > Regards, > > > --- > Masaru Nomiya mail-to: nomiya at ttmy.ne.jp > > "No Windows, no gains!" ..... "Why, I am wrong?" > > -- Bill -- -- John **= Email 9 ==========================** Date: Thu, 20 Jun 2002 15:52:58 -0400 From: Henry Sobotka Subject: Re: Mozilla collision with XFree86/OS2 Lyn St George wrote: > > On Thu, 20 Jun 2002 21:57:08 +0400 (MSD), nick wrote: > > It seems that both Mozilla and XFree86 use a dll called XPCOM.DLL. > This collision can have 2 results: > 1. If XFree is running, Mozilla will not start. > 2. If Mozilla is running, invoking 'startx' will reboot your machine:/ Where does the non-Mozilla xpcom dll come from? I don't see one here in XFree86/lib. h~ **= Email 10 ==========================** Date: Thu, 20 Jun 2002 18:03:51 +0200 (CDT) From: "Adrian Gschwend" Subject: unixos2 packages Hi all, Might be a stupid question but beside a zip file with the correct file structure, how should a unixos2 package look like? I want to finish openssh package for unixos2 nickk: are you on this list as well? If so, is it a big deal to compile the source with your changes? Would be nice if a make, make install does everything we need :-) cu Adrian -- Adrian Gschwend at OS/2 Netlabs ICQ: 22419590 ktk at netlabs.org ------- The OS/2 OpenSource Project: http://www.netlabs.org **= Email 11 ==========================** Date: Thu, 20 Jun 2002 18:58:10 -0400 From: Jack Troughton Subject: Re: Mozilla collision with XFree86/OS2 Lyn St George wrote: > On Thu, 20 Jun 2002 21:57:08 +0400 (MSD), nick wrote: > > It seems that both Mozilla and XFree86 use a dll called XPCOM.DLL. > This collision can have 2 results: > 1. If XFree is running, Mozilla will not start. > 2. If Mozilla is running, invoking 'startx' will reboot your machine:/ > > I've reported this through Bugzilla, and the answer from Mike > Kaply is, quoting: > =========== > "There's no way we're fixing this. Call this one an XFree86 bug. > > We need XPCOM.DLL. > > Michael Kaply > IBM Mozilla Advocate > Platform Owner - Mozilla for OS/2 > mkaply at us.ibm.com" > =========== > > Mozilla is too nice to just ditch. Can anyone think of some > way to run these together? "Set beginlibpath" is your friend:) Use it in the startx.cmd file to make sure xfree finds the right xpcom.dll. -- ------------------------------------------------------------------- * Jack Troughton jake at consultron.ca * * http://consultron.ca irc.ecomstation.ca * * Laval Qu‚bec Canada news://news.consultron.ca * ------------------------------------------------------------------- **= Email 12 ==========================** Date: Thu, 20 Jun 2002 19:12:52 +0100 From: John Poltorak Subject: Re: unixos2 packages On Thu, Jun 20, 2002 at 06:03:51PM +0200, Adrian Gschwend wrote: > Hi all, > > Might be a stupid question but beside a zip file with the correct file > structure, how should a unixos2 package look like? What I have done is take the equivalent SlackWare package and substitute all the OS/2 related files for those which are Linux specific, and then provide a PKGINFO file. > I want to finish openssh package for unixos2 > > nickk: are you on this list as well? If so, is it a big deal to compile > the source with your changes? Would be nice if a make, make install > does everything we need :-) A build script would be nice to have. > cu > > Adrian > > > -- > Adrian Gschwend > at OS/2 Netlabs > > ICQ: 22419590 > ktk at netlabs.org > ------- > The OS/2 OpenSource Project: > http://www.netlabs.org > -- John **= Email 13 ==========================** Date: Thu, 20 Jun 2002 19:22:17 +0000 From: "Lyn St George" Subject: Mozilla collision with XFree86/OS2 On Thu, 20 Jun 2002 21:57:08 +0400 (MSD), nick wrote: It seems that both Mozilla and XFree86 use a dll called XPCOM.DLL. This collision can have 2 results: 1. If XFree is running, Mozilla will not start. 2. If Mozilla is running, invoking 'startx' will reboot your machine:/ I've reported this through Bugzilla, and the answer from Mike Kaply is, quoting: =========== "There's no way we're fixing this. Call this one an XFree86 bug. We need XPCOM.DLL. Michael Kaply IBM Mozilla Advocate Platform Owner - Mozilla for OS/2 mkaply at us.ibm.com" =========== Mozilla is too nice to just ditch. Can anyone think of some way to run these together? - Cheers Lyn St George +--------------------------------------------------------------------------------- + http://www.zolotek.net .. eCommerce hosting, consulting + http://www.os2docs.org .. some 'How To' stuff ... +---------------------------------------------------------------------------------- **= Email 14 ==========================** Date: Thu, 20 Jun 2002 21:54:57 +0000 From: "Lyn St George" Subject: Re: Mozilla collision with XFree86/OS2 On Thu, 20 Jun 2002 15:52:58 -0400, Henry Sobotka wrote: >Lyn St George wrote: >> >> On Thu, 20 Jun 2002 21:57:08 +0400 (MSD), nick wrote: >> >> It seems that both Mozilla and XFree86 use a dll called XPCOM.DLL. >> This collision can have 2 results: >> 1. If XFree is running, Mozilla will not start. >> 2. If Mozilla is running, invoking 'startx' will reboot your machine:/ > >Where does the non-Mozilla xpcom dll come from? I don't see one here in >XFree86/lib. Hmm. I've finally found it in XWarpzilla, but it should be installed in bin/. It seems, IIRC, that it wouldn't run properly with xpcom.dll there so I moved it into lib/. I also see your notes there about the 2 X|Warpzillas not being compatible and not running together. Removing xpcom.dll from XFree86/lib removes the problem. I'll write to Mike K and apologise for the false alarm:/ >h~ > > - Cheers Lyn St George +--------------------------------------------------------------------------------- + http://www.zolotek.net .. eCommerce hosting, consulting + http://www.os2docs.org .. some 'How To' stuff ... +---------------------------------------------------------------------------------- **= Email 15 ==========================** Date: Thu, 20 Jun 2002 21:57:08 +0400 (MSD) From: "nick" Subject: Re: unixos2 packages On Thu, 20 Jun 2002 18:03:51 +0200 (CDT), Adrian Gschwend wrote: >Hi all, > >Might be a stupid question but beside a zip file with the correct file >structure, how should a unixos2 package look like? > >I want to finish openssh package for unixos2 > >nickk: are you on this list as well? If so, is it a big deal to compile >the source with your changes? Would be nice if a make, make install >does everything we need :-) yep, i am here ;) Its not very hard to compile from scratch, but the process is not fully automated yet ;) The makefile needs to be rewritten a bit. Also, the pcre and openssl libraries are needed to build openssh - i think, they must be incorporated in unixos2 tree too. Faithfully Yours, Nick **= Email 16 ==========================** Date: Thu, 20 Jun 2002 22:24:14 +0900 From: Masaru Nomiya Subject: Re: Re: Make v3.79.1 & Emacs Hello, In the Message; Subject : Re: Re: Make v3.79.1 & Emacs Message-ID : <20020619174935.Q91 at eyup.org> Date & Time: Wed, 19 Jun 2002 17:49:35 +0100 [John] == John Poltorak has written: John> Thanks for a copy of this - it really is an old program, one of the files John> is dated 33-09-02 ! :-) John> I can confirm that the included DISKACC.DLL gets rid of the previous tar John> error, but I just don't understand how that can happen since I don't see John> any reference to the DLL in GTAR258. I have no idea. John> This is very puzzling. How can it work? ....? I asked on the Japanese OS/2 users ML, but haven't got no answer about this. Mr. Nakagawa adviced me to use gunzip emacs-20.7-KIT1.9.tgz | tar xvf - This doesn't require diskacc.dll... Regards, --- Masaru Nomiya mail-to: nomiya at ttmy.ne.jp "No Windows, no gains!" ..... "Why, I am wrong?" -- Bill -- **= Email 17 ==========================** Date: Thu, 20 Jun 2002 22:36:38 +0900 From: Masaru Nomiya Subject: Re: Perl 5.8.0 - no progress Hello, In the Message; Subject : Re: Re: Perl 5.8.0 - no progress Message-ID : Date & Time: Sun, 16 Jun 2002 19:09:36 +0200 (CEST) [Stefan] == Stefan Neis has written: Me> Yes, it is written as I can't change LIBPATH. Me> But, except with #3, I got Me> ib/rx_rxu..........skipped: cannot find RXU.DLL Me> ..... Me> ib/rx_vrexx........skipped: cannot find VREXX.DLL Me> Me> Uh....,, mysterious..... Stefan> Not really. The bad test is relying on an environment variable Stefan> which normally doesn't exist on OS/2 (LIBPATH), but if you set Stefan> that variable to the "correct" value that bogus test will succeed. Stefan> And if your LIBPATH (the real one, not the useless environment Stefan> variable with the same name) contains the required DLLs as well, Stefan> the rest will work, too. Thanks, I could understand. In the statement; use OS2::REXX; $name = "VREXX"; $path = $ENV{LIBPATH} || $ENV{PATH} or die; foreach $dir (split(';', $path)) { next unless -f "$dir/$name.DLL"; $found = "$dir/$name.DLL"; print "# found at `$found'\n"; last; } ... $ENV{LIBPATH} is different from LIBPATH in CONFIG.SYS. I think, $ENV{LIBPATH} should be changed the one which would be read from CONFIG.SYS. But, how.... Regards, --- Masaru Nomiya mail-to: nomiya at ttmy.ne.jp "No Windows, no gains!" ..... "Why, I am wrong?" -- Bill --