From: UnixOS2 Archive To: "UnixOS2 Archive" Date: Mon, 17 Jun 2002 04:27:52 EST-10EDT,10,-1,0,7200,3,-1,0,7200,3600 Subject: [UnixOS2_Archive] No. 245 ************************************************** Sunday 16 June 2002 Number 245 ************************************************** Subjects for today 1 Re: Re: Perl 5.8.0 - no progress : Masaru Nomiya 2 Re: Make v3.79.1 & Emacs : Andreas Buening 3 Re: Wrong compiler flags : Andreas Buening 4 Re: Perl 5.8.0 - no progress : Masaru Nomiya 5 Re: DB_FILHA->PERLB12E.malloc : Henry Sobotka 6 Re: Re: Perl 5.8.0 - no progress : csaba.raduly at sophos.com 7 Symbolic Links : mikus at bga.com (Mikus Grinbergs) 8 Re: Re: Perl 5.8.0 - no progress : John Poltorak 9 Re: Make v3.79.1 & Emacs : Masaru Nomiya 10 DB_FILHA->PERLB12E.malloc : John Poltorak 11 Re: Make v3.79.1 & Emacs : John Poltorak 12 Re: DB_FILHA->PERLB12E.malloc : Henry Sobotka 13 Re: DB_FILHA->PERLB12E.malloc : John Poltorak 14 Re: DB_FILHA->PERLB12E.malloc : Henry Sobotka 15 Re: Symbolic Links : John Poltorak 16 Fwd: New Look! : Ted Sikora 17 Re: DB_FILHA->PERLB12E.malloc : John Poltorak 18 BLDLEVEL & PERL*.DLL : John Poltorak **= Email 1 ==========================** Date: Mon, 17 Jun 2002 00:10:31 +0900 From: Masaru Nomiya Subject: Re: Re: Perl 5.8.0 - no progress Hello, In the Message; Subject : Re: Re: Perl 5.8.0 - no progress Message-ID : <3D0C81B0.408D at axess.com> Date & Time: Sun, 16 Jun 2002 08:16:48 -0400 [Henry] == Henry Sobotka has written: John> What's the best way of changing this so that the LIBPATH is searched? :- John> John> use OS2::REXX; John> John> $path = $ENV{LIBPATH} || $ENV{PATH} or die; John> foreach $dir (split(';', $path)) { John> next unless -f "$dir/RXU.DLL"; John> $found = "$dir/RXU.DLL"; John> last; John> } Henry> The instant fix for the tests to pass is to add the locations of RXU.DLL Henry> and VREXX.DLL to PATH or move them into PATH. I found another solution. 1. copy VREXX.DLL and RXU.DLL to the directory in the LIBPATH 2. copy VREXX.EXE to the directory in the PATH 3. input g:\>SET LIBPATH=E:\OS2\DLL;G:\emx\dll; 4. run 'perl harness' lib/rx_rxu..........ok ..... lib/rx_vrexx........ok That is. LIBPATH statement lacks SET command. Regrads, --- Masaru Nomiya mail-to: nomiya at ttmy.ne.jp "No Windows, no gains!" ..... "Why, I am wrong?" -- Bill -- **= Email 2 ==========================** Date: Mon, 17 Jun 2002 00:21:00 +0200 From: Andreas Buening Subject: Re: Make v3.79.1 & Emacs John Poltorak wrote: > SYS1034: The system cannot find the command processor in the path > specified. > OS/2 Command Interpreter version 4.5 > > I'm not sure why this happens since c:\os2, where cmd.exe resides is on > the path at the time this ends. Hmm, I remember an error message like that. It's unlikely that the emacs Makefile needs cmd, so try set MAKESHELL=/bin/sh. Please tell me if you can build emacs, I couldn't. 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 3 ==========================** Date: Mon, 17 Jun 2002 00:22:12 +0200 From: Andreas Buening Subject: Re: Wrong compiler flags saba.raduly at sophos.com wrote: [snip] > >But what was the reason for this change? I see no real > >reason for this. Getting .obj files when using -Zomf has > >been a well documented (and also widely used) behaviour > >for years. > > EMX is one of the very very few gcc ports which does output > object files with .obj extension. EMX is also one of the very very few gcc ports which does output executable files with .exe extensions, libraries with .dll extension, recognizes .lib libraries, produces hello.exe from "gcc hello.c" instead of a.out, supports drive letters, backslashes. The problem with this change is that this is a major change of the gcc behaviour of an often used option. This requires changes in a lot of Makefiles and divides the Makefiles into pre gcc 3 Makefiles and post gcc 3 Makefiles. Life in the OS/2 world is even difficult enough without that. :-( There is no real reason why it should matter which gcc version you use for compiling something (in C). It should make no difference. If you don't need STL compliant C++ or you have a slow computer or a huge project gcc 2.95 may be still the better solution (not because gcc 3 is that slow but because the new C++ headers are _huge_). > >If anybody really really needs .o files why not > >add a -Zsuffix=o option? This wouldn't have broken a lot of > >Makefiles. How should a program (like libtool, for example) > >find out, whether it has to start ar or emxomfar or whether > >it needs a .lib or a .a import library for that dll? > > Surely ar can be made to recognize an a.out vs OMF file > (be it object or library) and launch emxomfar as needed > (or even link386, in effect merging ar and emxomfar). Ah, we've just found a volunteer? ;-) 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 4 ==========================** Date: Mon, 17 Jun 2002 01:31:52 +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 : <3D0CADE3.52B7 at axess.com> Date & Time: Sun, 16 Jun 2002 11:25:23 -0400 [Henry] == Henry Sobotka has written: Me> 1. copy VREXX.DLL and RXU.DLL to the directory in the LIBPATH Me> 2. copy VREXX.EXE to the directory in the PATH Me> 3. input Me> g:\>SET LIBPATH=E:\OS2\DLL;G:\emx\dll; Me> 4. run 'perl harness' Henry> Except that #3 is useless because you can't change LIBPATH directly with Henry> SET, just via BEGINLIBPATH or ENDLIBPATH. The tests are passing because Henry> the $ENV{PATH} condition now succeeds. Yes, it is written as I can't change LIBPATH. But, except with #3, I got ib/rx_rxu..........skipped: cannot find RXU.DLL ..... ib/rx_vrexx........skipped: cannot find VREXX.DLL Uh....,, mysterious..... Regards, and Good night --- Masaru Nomiya mail-to: nomiya at ttmy.ne.jp "No Windows, no gains!" ..... "Why, I am wrong?" -- Bill -- **= Email 5 ==========================** Date: Mon, 17 Jun 2002 10:10:00 -0400 From: Henry Sobotka Subject: Re: DB_FILHA->PERLB12E.malloc John Poltorak wrote: > > Every db.lib I've used, apart from one causes a number of errors like > this when building Perl 5.8.0 :- > > 06-14-2002 09:46:55 SYS2070 PID 3c11 TID 0001 Slot 00b7 > C:\EVAL\PERL-5.8\PERL\T\PERL.EXE > DB_FILHA->PERLB12E.malloc > 127 > > Can anyone tell me what is going wrong here? It means malloc() isn't being found in perlb12e.dll. Grep perl5.def to see if it's missing from EXPORTS and, if it is, check what's happening when malloc.obj gets built. h~ **= Email 6 ==========================** Date: Mon, 17 Jun 2002 10:30:27 +0100 From: csaba.raduly at sophos.com Subject: Re: Re: Perl 5.8.0 - no progress On 16/06/2002 16:25:23 owner-os2-unix wrote: >Masaru Nomiya wrote: >> >> I found another solution. >> >> 1. copy VREXX.DLL and RXU.DLL to the directory in the LIBPATH >> 2. copy VREXX.EXE to the directory in the PATH >> 3. input >> g:\>SET LIBPATH=E:\OS2\DLL;G:\emx\dll; >> 4. run 'perl harness' >> >> lib/rx_rxu..........ok >> ..... >> lib/rx_vrexx........ok >> >> That is. LIBPATH statement lacks SET command. > >Except that #3 is useless because you can't change LIBPATH directly with >SET, just via BEGINLIBPATH or ENDLIBPATH. The tests are passing because >the $ENV{PATH} condition now succeeds. > In effect, there are two completely different things here: LIBPATH, as used by OS/2 to find DLLs, and an environment variable, which as it happens is called LIBPATH. It could have been called RUMPERLSTILTSKIN for the same effect (as long as the scripts test for the same env. variable). The test should be rewritten to just try to load RXU.DLL; OS/2 will find it in the LIBPATH if it's there. If this was by IlyaZ I'm quite surprised. He ought to know OS/2 better than that. -- Csaba Ráduly, Software Engineer Sophos Anti-Virus email: csaba.raduly at sophos.com http://www.sophos.com US Support: +1 888 SOPHOS 9 UK Support: +44 1235 559933 **= Email 7 ==========================** Date: Mon, 17 Jun 2002 13:13:14 -0500 From: mikus at bga.com (Mikus Grinbergs) Subject: Symbolic Links On Tue, 18 Jun 2002 00:43:18 +0900 Masaru Nomiya wrote: > > Mr, Sasaki ... recommended to rename gnu patch,exe as > gpatch.exe to prevent from confusion caused by working > PATCH.EXE of > OS/2 native. Here's a proposal. (And no, I am __not__ volunteering.) Recently had the occasion to explain Odin's WIN32K.SYS to another user. My concept of one of its functions: When what is to be loaded from disk is a windows-native program module, win32k.sys (et al) intercept the load-flow and transform the file-on-disk into something that OS/2 services *can* load. Now suppose there existed a module LNKSYM.SYS (et al), hooked into the OS/2 kernel the same way that win32k.sys is, which when what is to be loaded from disk is a file having the "OS/2 Type" of "SymbolicLink" [alternatively, it could test an unique string found at the beginning of the file], lnksym.sys (et al) would intercept the load-flow, would extract the full pathname given by the content of the file-on-disk, and would tell OS/2 to load __that__ file instead. mikus **= Email 8 ==========================** Date: Mon, 17 Jun 2002 13:45:40 +0100 From: John Poltorak Subject: Re: Re: Perl 5.8.0 - no progress On Mon, Jun 17, 2002 at 10:30:27AM +0100, csaba.raduly at sophos.com wrote: > > In effect, there are two completely different things here: > LIBPATH, as used by OS/2 to find DLLs, and an environment variable, which > as it happens is called LIBPATH. It could have been called RUMPERLSTILTSKIN > for the same effect (as long as the scripts test for the same env. > variable). The test should be rewritten to just try to load RXU.DLL; How would you try to do this using Perl? > OS/2 > will find it in the LIBPATH if it's there. If this was by IlyaZ I'm quite > surprised. He ought to know OS/2 better than that. The VREXX test contains this:- OS2::REXX::_set("MBOX.0" => 4, "MBOX.1" => "Perl VREXX Access Test", "MBOX.2" => "", "MBOX.3" => "(C) Andreas Kaiser", "MBOX.4" => "December 1994") So I suspect it has been in there for a long time. -- John **= Email 9 ==========================** Date: Mon, 17 Jun 2002 14:07:08 +0900 From: Masaru Nomiya Subject: Re: Make v3.79.1 & Emacs Hello, In the Message; Subject : Re: Make v3.79.1 & Emacs Message-ID : <3D0D0F4C.6D36 at nexgo.de> Date & Time: Mon, 17 Jun 2002 00:21:00 +0200 [Andreas] == Andreas Buening has written: John> I'm not sure why this happens since c:\os2, where cmd.exe resides is on John> the path at the time this ends. Andreas> Hmm, I remember an error message like that. It's unlikely Andreas> that the emacs Makefile needs cmd, so try set MAKESHELL=/bin/sh. By this, I could build Emacs 20.7. Thanks. Regards, --- Masaru Nomiya mail-to: nomiya at ttmy.ne.jp "Bill! You married with Computers. Not with Me!" "No..., with money." **= Email 10 ==========================** Date: Mon, 17 Jun 2002 14:29:00 +0100 From: John Poltorak Subject: DB_FILHA->PERLB12E.malloc Every db.lib I've used, apart from one causes a number of errors like this when building Perl 5.8.0 :- 06-14-2002 09:46:55 SYS2070 PID 3c11 TID 0001 Slot 00b7 C:\EVAL\PERL-5.8\PERL\T\PERL.EXE DB_FILHA->PERLB12E.malloc 127 Can anyone tell me what is going wrong here? -- John **= Email 11 ==========================** Date: Mon, 17 Jun 2002 15:56:16 +0100 From: John Poltorak Subject: Re: Make v3.79.1 & Emacs On Mon, Jun 17, 2002 at 12:21:00AM +0200, Andreas Buening wrote: > John Poltorak wrote: > > > SYS1034: The system cannot find the command processor in the path > > specified. > > OS/2 Command Interpreter version 4.5 > > > > I'm not sure why this happens since c:\os2, where cmd.exe resides is on > > the path at the time this ends. > > Hmm, I remember an error message like that. It's unlikely > that the emacs Makefile needs cmd, so try set MAKESHELL=/bin/sh. > Please tell me if you can build emacs, I couldn't. I have managed to build emacs in the past but it does require some manual intervention, which tends to be error prone. I'd like to have things as automated as possible. One problem I have encountered is the requirement for untgz... For some reason 'tar zxf' does not work 'emacs-20.7-KIT1.9.tgz' although 'gzip -d' followed by 'tar xf' does. I've never understood why. Another thing which can catch you out is the use of GPATCH by default, which I do not have under this name, I always call it PATCH. > > bye, > Andreas -- John **= Email 12 ==========================** Date: Mon, 17 Jun 2002 16:50:27 -0400 From: Henry Sobotka Subject: Re: DB_FILHA->PERLB12E.malloc John Poltorak wrote: > > This is what I get:- > > "Perl_malloc" at 772 > "Perl_safesysmalloc" at 897 Perl_malloc is not the same as malloc. Could be that the default configuration has been changed to use Perl_malloc rather than malloc (which DB_File is trying to call). h~ **= Email 13 ==========================** Date: Mon, 17 Jun 2002 17:01:15 +0100 From: John Poltorak Subject: Re: DB_FILHA->PERLB12E.malloc On Mon, Jun 17, 2002 at 10:10:00AM -0400, Henry Sobotka wrote: > John Poltorak wrote: > > > > Every db.lib I've used, apart from one causes a number of errors like > > this when building Perl 5.8.0 :- > > > > 06-14-2002 09:46:55 SYS2070 PID 3c11 TID 0001 Slot 00b7 > > C:\EVAL\PERL-5.8\PERL\T\PERL.EXE > > DB_FILHA->PERLB12E.malloc > > 127 > > > > Can anyone tell me what is going wrong here? > > It means malloc() isn't being found in perlb12e.dll. Grep perl5.def to > see if it's missing from EXPORTS and, if it is, check what's happening > when malloc.obj gets built. This is what I get:- "Perl_malloc" at 772 "Perl_safesysmalloc" at 897 and I can see these two instances in the DLL when using a file viewer. These errors seem to occur when running tests related to db.lib, but I'm not sure how to confirm this... > h~ -- John **= Email 14 ==========================** Date: Mon, 17 Jun 2002 18:47:42 -0400 From: Henry Sobotka Subject: Re: DB_FILHA->PERLB12E.malloc John Poltorak wrote: > > How do I confirm this? If you grep config.sh for malloc, you should see the following among the output: d_mymalloc='define' mallocobj='malloc.obj' mallocsrc='malloc.c' usemymalloc='y' You may have d_mymalloc undefined and usemymalloc set to n. > Does this require changes to db.lib to cope with such changes? No, it's strictly a Perl matter. h~ **= Email 15 ==========================** Date: Mon, 17 Jun 2002 20:19:32 +0100 From: John Poltorak Subject: Re: Symbolic Links On Mon, Jun 17, 2002 at 01:13:14PM -0500, Mikus Grinbergs wrote: > On Tue, 18 Jun 2002 00:43:18 +0900 Masaru Nomiya wrote: > > > > Mr, Sasaki ... recommended to rename gnu patch,exe as > > gpatch.exe to prevent from confusion caused by working > > PATCH.EXE of > OS/2 native. > > Here's a proposal. (And no, I am __not__ volunteering.) > > Recently had the occasion to explain Odin's WIN32K.SYS to another > user. My concept of one of its functions: When what is to be > loaded from disk is a windows-native program module, win32k.sys > (et al) intercept the load-flow and transform the file-on-disk > into something that OS/2 services *can* load. > > Now suppose there existed a module LNKSYM.SYS (et al), hooked > into the OS/2 kernel the same way that win32k.sys is, which > when what is to be loaded from disk is a file having the "OS/2 > Type" of "SymbolicLink" [alternatively, it could test an unique > string found at the beginning of the file], lnksym.sys (et al) > would intercept the load-flow, would extract the full pathname > given by the content of the file-on-disk, and would tell OS/2 > to load __that__ file instead. AIUI symbolic links is one of the features which we should see in LIBEMU. > mikus -- John **= Email 16 ==========================** Date: Mon, 17 Jun 2002 21:24:54 -0400 From: Ted Sikora Subject: Fwd: New Look! ---------- Forwarded Message ---------- Subject: New Look! Date: Mon, 17 Jun 2002 21:23:49 -0400 From: Ted Sikora To: announce at unixos2.com Finally made UnixOS2.org worthy of the new Mozilla.(I hope!) A cleaner sleeker faster site. Now looks the same under every imaginable browser available. Comments welcome. -- Ted Sikora tsikora at unixos2.com http://unixos2.com ------------------------------------------------------- -- -- Ted Sikora tsikora at unixos2.com http://unixos2.com **= Email 17 ==========================** Date: Mon, 17 Jun 2002 23:18:24 +0100 From: John Poltorak Subject: Re: DB_FILHA->PERLB12E.malloc On Mon, Jun 17, 2002 at 04:50:27PM -0400, Henry Sobotka wrote: > John Poltorak wrote: > > > > This is what I get:- > > > > "Perl_malloc" at 772 > > "Perl_safesysmalloc" at 897 > > Perl_malloc is not the same as malloc. > > Could be that the default configuration has been changed to use > Perl_malloc rather than malloc (which DB_File is trying to call). How do I confirm this? Does this require changes to db.lib to cope with such changes? > h~ -- John **= Email 18 ==========================** Date: Mon, 17 Jun 2002 23:30:25 +0100 From: John Poltorak Subject: BLDLEVEL & PERL*.DLL I've just found the BLDLEVEL works on Perl*.DLL, which is handy to know... Here's what I get with a recent build:- C:\eval\perl\perl-5.8.0-RC1\t>bldlevel perlB12E.dll Build Level Display Facility Version 5.59.105 Mar 15 1999 (C) Copyright IBM Corporation 1993-1999 Signature: at #perl5-porters at perl.org:5.008# at Perl interpreter, configured as -Dusedevel -des -D prefix=c:/usr/lib/perl Vendor: perl5-porters at perl.org Revision: 5.08.008 File Version: 5.8 Description: Perl interpreter, configured as -Dusedevel -des -D prefix=c:/usr/lib/perl -- John