Re: pkg/32867 (pkgsrc/wip/jdk14 patch fails)

["Chuck Zmudzinski" <brchuck%hotmail.com@localhost>]

The following reply was made to PR pkg/32867; it has been noted by GNATS.

From: "Chuck Zmudzinski" <brchuck%hotmail.com@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: netbsd-java%NetBSD.org@localhost, ghen%netbsd.org@localhost
Subject: Re: pkg/32867 (pkgsrc/wip/jdk14 patch fails)
Date: Mon, 20 Feb 2006 22:45:13 -0500

 >From: ghen%netbsd.org@localhost
 >Reply-To: gnats-bugs%netbsd.org@localhost
 >To: ghen%netbsd.org@localhost, pkgsrc-bugs%netbsd.org@localhost, 
 >gnats-admin%netbsd.org@localhost,ghen%netbsd.org@localhost, 
 >brchuck%hotmail.com@localhost
 >Subject: Re: pkg/32867 (pkgsrc/wip/jdk14 patch fails)
 >Date: Sat, 18 Feb 2006 22:49:40 +0000 (UTC)
 >
 >Synopsis: pkgsrc/wip/jdk14 patch fails
 >
 >State-Changed-From-To: open->closed
 >State-Changed-By: ghen%netbsd.org@localhost
 >State-Changed-When: Sat, 18 Feb 2006 22:49:39 +0000
 >State-Changed-Why:
 >The patch stage was broken on pkgsrc-HEAD in the same way a couple of weeks
 >ago.  This was caused by ^M (Carriage Return) characters in the Eyesbeyond
 >patchset.  Since the wip/jdk14 package itself didn't change, it must have 
 >been
 >some change in the pkgsrc infrastructure which caused this failure (I still
 >haven't figured out what exactly broke it).  I then committed a simple
 >workaround for this: SUBST the ^M characters out of the patchset before
 >applying the patches.
 
 I noticed that in the Makefile
 
 >
 >Apparantly this broke it on pkgsrc-2005Q4 systems (which were ok before) in
 >turn.  Your patch (add -a to unzip's arguments) fixes it when combined with 
 >my
 >earlier fix, so now it works on both pkgsrc-2005Q4 and pkgsrc-HEAD.  Thanks 
 >for
 >the patch!
 
 Glad to be of help to others.
 
 The only other problem I had was during the build - I got a seg fault from 
 gcc3 when compiling
 work/hotspot/src/share/vm/opto/parse2.cpp until I maxed out the limits such 
 as datasize, stackzize, memoryuse, and memorylocked. I tried first just 
 increasing the datasize and stacksize, and after tripling datasize and 
 doubling stacksize it still didn't work, so I just decided to max out all 
 four of those limits and finally it worked. Perhaps a hint about this 
 problem that can occur during the build could be displayed at the beginning 
 of the build. Increasing the datasize to 262144 according to the 
 instructions on the sun-java linux emulation packages was not good enough 
 for me. Anyway, thanks for you good work.
 
 Chuck Zmudzinski