From: UnixOS2 Archive To: "UnixOS2 Archive" Date: Tue, 18 Jun 2002 04:27:55 EST-10EDT,10,-1,0,7200,3,-1,0,7200,3600 Subject: [UnixOS2_Archive] No. 246 ************************************************** Monday 17 June 2002 Number 246 ************************************************** Subjects for today 1 Re: Make v3.79.1 & Emacs : Masaru Nomiya 2 Re: DB_FILHA->PERLB12E.malloc : John Poltorak 3 Re: DB_FILHA->PERLB12E.malloc : Henry Sobotka 4 Re: DB_FILHA->PERLB12E.malloc : Henry Sobotka 5 Re: Re: Make v3.79.1 & Emacs : John Poltorak 6 Re: Re: Make v3.79.1 & Emacs : John Poltorak 7 Re: DB_FILHA->PERLB12E.malloc : John Poltorak 8 Re: Re: Make v3.79.1 & Emacs : John Poltorak 9 Re: Make v3.79.1 & Emacs : Masaru Nomiya 10 Re: libtool and -version-info : paul-biz" 11 Re: Make v3.79.1 & Emacs : Masaru Nomiya 12 Re: libtool and -version-info : Thomas Hoffmann 13 Re: Make v3.79.1 & Emacs : Masaru Nomiya 14 packages in unixos2-current:SCRIPT function ... : Thomas Hoffmann **= Email 1 ==========================** Date: Tue, 18 Jun 2002 00:43:18 +0900 From: Masaru Nomiya Subject: Re: Make v3.79.1 & Emacs Hello, In the Message; Subject : Re: Make v3.79.1 & Emacs Message-ID : <20020617155616.G91 at eyup.org> Date & Time: Mon, 17 Jun 2002 15:56:16 +0100 [John] == John Poltorak has written: John> I'd like to have things as automated as possible. Yes, I know well. John> One problem I have encountered is the requirement for untgz... For some John> reason 'tar zxf' does not work 'emacs-20.7-KIT1.9.tgz' although 'gzip -d'John> followed by 'tar xf' does. I've never understood why. I'll ask Mr. Nakagawa about this. John> Another thing which can catch you out is the use of GPATCH by default, John> which I do not have under this name, I always call it PATCH. Mr, Sasaki, great porter (we have heard nothing from him for a long time), intended that all the OS/2 user could build Emacs with ease and without encountering any problems. As a part of his purpose, he recommended to rename gnu patch,exe as gpatch.exe to prevent from confusion caused by working PATCH.EXE of OS/2 native. As you could imagine from this, he wrote detailed Readme.OS2. I must translate... Regards, --- Masaru Nomiya mail-to: nomiya at ttmy.ne.jp "No Windows, no gains!" ..... "Why, I am wrong?" -- Bill -- **= Email 2 ==========================** Date: Tue, 18 Jun 2002 10:03:34 +0100 From: John Poltorak Subject: Re: DB_FILHA->PERLB12E.malloc On Mon, Jun 17, 2002 at 06:47:42PM -0400, Henry Sobotka wrote: > 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' Here's what I get:- d_mymalloc='define' i_malloc='define' libswanted='... malloc ...' mallocobj='malloc.obj' mallocsrc='malloc.c' malloctype='void *' usemymalloc='y' > You may have d_mymalloc undefined and usemymalloc set to n. Nope... Anything else to try? > h~ -- John **= Email 3 ==========================** Date: Tue, 18 Jun 2002 11:25:16 -0400 From: Henry Sobotka Subject: Re: DB_FILHA->PERLB12E.malloc John Poltorak wrote: > > Anything else to try? emxexp malloc.obj If it exports Perl_malloc instead of malloc, the question becomes why wasn't the call to malloc in DB_File changed to Perl_malloc? This wasn't a problem with 5.7.3, so there should be a note about malloc/Perl_malloc in the Changes log for the past few months. h~ **= Email 4 ==========================** Date: Tue, 18 Jun 2002 12:34:35 -0400 From: Henry Sobotka Subject: Re: DB_FILHA->PERLB12E.malloc John Poltorak wrote: > > I found this line in ext\DB_File\Makefile :- > > PERL_MALLOC_DEF = -DPERL_EXTMALLOC_DEF -Dmalloc=Perl_malloc -Dfree=Perl_mfree -Drealloc=Perl_realloc -Dcalloc=Perl_calloc > > I guess this is something I've generated, so is there something odd in my > environment causing this? That's exactly what I've got here in the 5.7.3 Makefile. > I found this in Changes5.6: > > [ 3790] By: gsar on 1999/07/27 07:45:08 > Log: provide MakeMaker attribute PERL_MALLOC_OK that allows extensions > to call Perl_malloc() as malloc() (from Ilya Zakharevich) > Branch: perl > ! ext/SDBM_File/Makefile.PL lib/ExtUtils/MM_Unix.pm > ! lib/ExtUtils/MakeMaker.pm os2/OS2/REXX/Makefile.PL perl.h > ____________________________________________________________________________ > > Is this relevant? Yes, it suggests that adding "PERL_MALLOC_OK => 1" to the DB_File Makefile.PL as in the SDBM_File or REXX Makefile.PL's might fix the problem. To understand why it's happening you would have to look at the diffs between 5.7.3 and 5.8.0. h~ **= Email 5 ==========================** Date: Tue, 18 Jun 2002 12:53:04 +0100 From: John Poltorak Subject: Re: Re: Make v3.79.1 & Emacs On Tue, Jun 18, 2002 at 08:39:51PM +0900, Masaru Nomiya wrote: > Hello, > > In the Message; > > Subject : Re: Make v3.79.1 & Emacs > Message-ID : <8z5d29nt.wl%nomiya at ttmy.ne.jp> > Date & Time: Tue, 18 Jun 2002 00:43:18 +0900 > > [Me] == Masaru Nomiya has written: > > John> One problem I have encountered is the requirement for untgz... For some > John> reason 'tar zxf' does not work 'emacs-20.7-KIT1.9.tgz' although 'gzip -d'John> followed by 'tar xf' does. I've never understood why. > > Me> I'll ask Mr. Nakagawa about this. > > I asked. The answer is "tar zxf works". > > In fact, I could do this (What did I do....?). > > Environment; > > GNU tar version 1.10 - AK 2.58 > gzip 1.2.4 (18 Aug 93) Normally, it should work just like this:- tar zxf emacs-20.7-KIT1.9.tgz but when I last tried I got this error message:- tar: archive emacs-20.7-KIT1.9.tgz EOF not on block boundary and archive did not extract fully. I have not seen this happen before and don't know if it is related to anything in my environment. > --- > Masaru Nomiya mail-to: nomiya at ttmy.ne.jp > > "No Windows, no gains!" ..... "Why, I am wrong?" > > -- Bill -- -- John **= Email 6 ==========================** Date: Tue, 18 Jun 2002 14:28:23 +0100 From: John Poltorak Subject: Re: Re: Make v3.79.1 & Emacs On Tue, Jun 18, 2002 at 09:06:54PM +0900, Masaru Nomiya wrote: > Hello, > > John> Normally, it should work just like this:- > > John> tar zxf emacs-20.7-KIT1.9.tgz > > John> but when I last tried I got this error message:- > > John> tar: archive emacs-20.7-KIT1.9.tgz EOF not on block boundary > > The file you got might be broken. > > I executed md5sum and got result as follows; > > [G:\work]md5sum emacs-20.7-KIT1.9.tgz > b68f945075d9139ce1713c4e599130ba *emacs-20.7-KIT1.9.tgz > > Is this same as yours? It's exactly the same, I just tried. Don't you get this error msg? > Regrads, > > --- > Masaru Nomiya mail-to: nomiya at ttmy.ne.jp > > "No Windows, no gains!" ..... "Why, I am wrong?" > > -- Bill -- -- John **= Email 7 ==========================** Date: Tue, 18 Jun 2002 16:46:16 +0100 From: John Poltorak Subject: Re: DB_FILHA->PERLB12E.malloc On Tue, Jun 18, 2002 at 11:25:16AM -0400, Henry Sobotka wrote: > John Poltorak wrote: > > > > Anything else to try? > > emxexp malloc.obj C:\eval\perl\perl-5.8.0-RC1>c:\emx\bin\emxexp malloc.obj ; From malloc.obj "Perl_malloced_size" "Perl_malloc" "Perl_mfree" "Perl_realloc" "Perl_calloc" "Perl_strdup" "Perl_putenv" "Perl_get_mstats" "Perl_dump_mstats" > If it exports Perl_malloc instead of malloc, the question becomes why > wasn't the call to malloc in DB_File changed to Perl_malloc? What exactly should I be looking for? I found this line in ext\DB_File\Makefile :- PERL_MALLOC_DEF = -DPERL_EXTMALLOC_DEF -Dmalloc=Perl_malloc -Dfree=Perl_mfree -Drealloc=Perl_realloc -Dcalloc=Perl_calloc I guess this is something I've generated, so is there something odd in my environment causing this? > This wasn't a problem with 5.7.3, so there should be a note about > malloc/Perl_malloc in the Changes log for the past few months. I found this in Changes5.6: [ 3790] By: gsar on 1999/07/27 07:45:08 Log: provide MakeMaker attribute PERL_MALLOC_OK that allows extensions to call Perl_malloc() as malloc() (from Ilya Zakharevich) Branch: perl ! ext/SDBM_File/Makefile.PL lib/ExtUtils/MM_Unix.pm ! lib/ExtUtils/MakeMaker.pm os2/OS2/REXX/Makefile.PL perl.h ____________________________________________________________________________ Is this relevant? > h~ -- John **= Email 8 ==========================** Date: Tue, 18 Jun 2002 17:22:15 +0100 From: John Poltorak Subject: Re: Re: Make v3.79.1 & Emacs On Wed, Jun 19, 2002 at 01:07:44AM +0900, Masaru Nomiya wrote: > > John> Normally, it should work just like this:- > > John> tar zxf emacs-20.7-KIT1.9.tgz > > John> but when I last tried I got this error message:- > > John> tar: archive emacs-20.7-KIT1.9.tgz EOF not on block boundary > > I found. > > I renamed diskacc.dll as diskacc.dl_, then executed tar command. > I got same result as yours. > > [G:\work]tar zxf emacs-20.7-KIT1.9.tgz > tar: archive emacs-20.7-KIT1.9.tgz EOF not on block boundary > > That is, you haven't installed diskacc.dll of GNUTAR.ZIP. I don't see a diskacc.dll in GTAR258.ZIP. Which GNUTAR.ZIP are you referring to? > Regards, and good night. > > --- > Masaru Nomiya mail-to: nomiya at ttmy.ne.jp > > "No Windows, no gains!" ..... "Why, I am wrong?" > > -- Bill -- -- John **= Email 9 ==========================** Date: Tue, 18 Jun 2002 20:39:51 +0900 From: Masaru Nomiya Subject: Re: Make v3.79.1 & Emacs Hello, In the Message; Subject : Re: Make v3.79.1 & Emacs Message-ID : <8z5d29nt.wl%nomiya at ttmy.ne.jp> Date & Time: Tue, 18 Jun 2002 00:43:18 +0900 [Me] == Masaru Nomiya has written: John> One problem I have encountered is the requirement for untgz... For some John> reason 'tar zxf' does not work 'emacs-20.7-KIT1.9.tgz' although 'gzip -d'John> followed by 'tar xf' does. I've never understood why. Me> I'll ask Mr. Nakagawa about this. I asked. The answer is "tar zxf works". In fact, I could do this (What did I do....?). Environment; GNU tar version 1.10 - AK 2.58 gzip 1.2.4 (18 Aug 93) --- Masaru Nomiya mail-to: nomiya at ttmy.ne.jp "No Windows, no gains!" ..... "Why, I am wrong?" -- Bill -- **= Email 10 ==========================** Date: Tue, 18 Jun 2002 20:48:50 -0500 (CDT) From: "paul-biz" Subject: Re: libtool and -version-info On Tue, 18 Jun 2002 22:40:23 +0100, Thomas Hoffmann wrote: >paul-biz schrieb: >> >> example of error: >> >> libtool: link: CURRENT `0:28:0' is not a nonnegative integer >> libtool: link: `0:28:0' is not valid version information >> >I noticed a similar problem when building R: and I had to find out that >"expr.exe" from sh-utils does not work correctly. > >This is > >F:\Zip\new\unixos2>expr --version >expr - GNU sh-utils 1.12 > >I did enter the version number manually, then. But this of course is no >real solution. > >Thomas. Using the sh-utils 2.0 from Jun Sawataishi which contains a new build of expr but I still have the same problem. I have found that if I use KSH instead of BASH, the libtool will work without changes. Or, cut out the version-number-validation part of libtool and it will work in BASH. So is BASH broken anyway across platforms, or is just the OS/2 port having a fit with this? The bash i'm using is "GNU bash, version 2.00.0(266)-release (i386-ibm-os2)" This is the segment that fails: # Check that each of the things are valid numbers. case $current in 0 | [1-9] | [1-9][0-9] | [1-9][0-9][0-9]) ;; *) $echo "$modename: CURRENT \`$current' is not a nonnegative integer" 1>&2 $echo "$modename: \`$vinfo' is not valid version information" 1>&2 exit 1 ;; esac Thanks, Paul **= Email 11 ==========================** Date: Tue, 18 Jun 2002 21:06:54 +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 : <20020618125304.W91 at eyup.org> Date & Time: Tue, 18 Jun 2002 12:53:04 +0100 [John] == John Poltorak has written: John> Normally, it should work just like this:- John> tar zxf emacs-20.7-KIT1.9.tgz John> but when I last tried I got this error message:- John> tar: archive emacs-20.7-KIT1.9.tgz EOF not on block boundary The file you got might be broken. I executed md5sum and got result as follows; [G:\work]md5sum emacs-20.7-KIT1.9.tgz b68f945075d9139ce1713c4e599130ba *emacs-20.7-KIT1.9.tgz Is this same as yours? Regrads, --- Masaru Nomiya mail-to: nomiya at ttmy.ne.jp "No Windows, no gains!" ..... "Why, I am wrong?" -- Bill -- **= Email 12 ==========================** Date: Tue, 18 Jun 2002 22:40:23 +0100 From: Thomas Hoffmann Subject: Re: libtool and -version-info I noticed a similar problem when building R: and I had to find out that "expr.exe" from sh-utils does not work correctly. This is F:\Zip\new\unixos2>expr --version expr - GNU sh-utils 1.12 I did enter the version number manually, then. But this of course is no real solution. Thomas. paul-biz schrieb: > > Hi, > > I get this error all the time when trying to configure & make stuff. > It's trying to set a version number from libtool and it never likes > it... If I remove it, everything "seems" to be OK, but I'd like to find > out if it's just me or if it's normal... In this case I'm using GCC > 3.0.3 > > example of error: > > libtool: link: CURRENT `0:28:0' is not a nonnegative integer > libtool: link: `0:28:0' is not valid version information > > Thanks, > Paul -- Thomas Hoffmann Telephone: 49-351-4598831 thoffman at zappa.sax.de Dresden, Germany ..sig under construction ... **= Email 13 ==========================** Date: Tue, 18 Jun 2002 23:10:45 +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 : <20020618142823.X91 at eyup.org> Date & Time: Tue, 18 Jun 2002 14:28:23 +0100 [John] == John Poltorak has written: John> Normally, it should work just like this:- John> John> tar zxf emacs-20.7-KIT1.9.tgz John> John> but when I last tried I got this error message:- John> John> tar: archive emacs-20.7-KIT1.9.tgz EOF not on block boundary John> Me> The file you got might be broken. Me> Me> I executed md5sum and got result as follows; Me> Me> [G:\work]md5sum emacs-20.7-KIT1.9.tgz Me> b68f945075d9139ce1713c4e599130ba *emacs-20.7-KIT1.9.tgz Me> Me> Is this same as yours? John> It's exactly the same, I just tried. Is it! John> Don't you get this error msg? No, I hven't got. --- Masaru Nomiya mail-to: nomiya at ttmy.ne.jp "No Windows, no gains!" ..... "Why, I am wrong?" -- Bill -- **= Email 14 ==========================** Date: Tue, 18 Jun 2002 23:34:03 +0100 From: Thomas Hoffmann Subject: packages in unixos2-current:SCRIPT function ... The last days I tried to setup a fresh unixos2 environment using the packages from unixos2.com. I used the installpkd.cmd file and noted that most of the packages contain in their "install" subdir a shell script named "install.sh". This file is not mentioned in the PKGINFO file and so is not used for the installation at all. Now installpkg.cmd facilitates REXX install scripts, that have to be mentioned in the PKGINFO file under the SCRIPT keyword. Is there a reason that nearly in no package it was attempted to understand the install.sh file, translate it to REXX and introduce it into PKGINFO using a SCRIPT line? PS. Who hides behind these "maintainer" addresses? There are more different addresses than OS/2 user left over.. (okay, okay, this wasjust a joke ;-)) -- Thomas Hoffmann Telephone: 49-351-4598831 thoffman at zappa.sax.de Dresden, Germany ..sig under construction ...