From owner-freebsd-ports@freebsd.org Thu Jan 26 00:12:45 2017 Return-Path: Delivered-To: freebsd-ports@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 81CA0CC1EF1 for ; Thu, 26 Jan 2017 00:12:45 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 713A41FE2 for ; Thu, 26 Jan 2017 00:12:45 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: by mailman.ysv.freebsd.org (Postfix) id 6D18FCC1EEF; Thu, 26 Jan 2017 00:12:45 +0000 (UTC) Delivered-To: ports@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6C7EBCC1EED; Thu, 26 Jan 2017 00:12:45 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from gw.catspoiler.org (unknown [IPv6:2602:304:b010:ef20::f2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gw.catspoiler.org", Issuer "gw.catspoiler.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 3AECC1FE0; Thu, 26 Jan 2017 00:12:45 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.15.2/8.15.2) with ESMTP id v0Q0CXKj013197; Wed, 25 Jan 2017 16:12:37 -0800 (PST) (envelope-from truckman@FreeBSD.org) Message-Id: <201701260012.v0Q0CXKj013197@gw.catspoiler.org> Date: Wed, 25 Jan 2017 16:12:33 -0800 (PST) From: Don Lewis Subject: Re: unable to build java in poudriere To: ultima1252@gmail.com cc: julian@freebsd.org, ports@freebsd.org, java@freebsd.org In-Reply-To: MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2017 00:12:45 -0000 On 25 Jan, Ultima wrote: > I just finished building openjdk8 with a fresh repo and it built just fine. > > poudriere bulk -p git -j 103amd64 java/openjdk8 > ref: > https://poudriere.ultimasbox.com/build.html?mastername=103amd64-git&build=2017-01-25_14h51m15s > > > > A google search on the error suggests that it is most likely related to > some form of memory issue. > > If you follow this post from a few years ago, it could lead you to the same > conclusion. More or less it seemed to be a problem with java determining > incorrect memory values which was causing that error. Could be completely > wrong but it is worth looking into. > > https://lists.freebsd.org/pipermail/freebsd-java/2013-December/010441.html > > Explicit setting maximum memory starts the vm, but being that this is a > port building, I'm not really sure what to suggest. I guess you could try > add an arg on the Makefile setting max memory, but I'm not sure how much > memory it requires to build. I know building openjdk does need quite a bit. > Another solution, likely less desired is using another system to build it > or using the FreeBSD repo to download it. Sorry if this isn't helpful. > Someone else may have a better solution. > > Good luck, > Ultima > > On Wed, Jan 25, 2017 at 5:48 AM, Julian Elischer wrote: > >> On 25/1/17 6:30 pm, Julian Elischer wrote: >> >>> On 25/1/17 10:36 am, Ultima wrote: >>> >>>> Sorry Julian but your details are kind of vague. Are you on head? I'm >>>> not sure when my last build for openjdk7 or 8 were but I have them built in >>>> my repo. Is there enough memory on the system building it? or is it >>>> limited? that is usually the culprit for the openjdk ports. >>>> >>>> I ask if you were on head because I know java was broken for sometime in >>>> January but was fixed, or at least r312388 is working. >>>> >>> Sorry, one item missing.. compile is on FreeBSD 10.3 >>> >>> Poudriere is populated with the head ports tree as of yesterday, but I >>> had hte same problem a few weeks ago. >>> the list of packages includes openjdk8 >>> it would probably have the same issue if openjdk8 was the ONLY port to >>> make, because jdk8 wants jdk7 to jdb7 won't build. >>> Should poudriere or ports give a warning "you need to install package X >>> before we can do this compile"? >>> >> >> I will add that bootstrap-openjdk-r351880_1.txz is already finished and >> available. >> I'm guessing that openjdk7 should be using that, but isn't for some reason. >> >> in fact is it possible that 8 should be using that to bootstrap itself up >> as well instead of using 7? >> >> I'm not experienced with java, I just need to get it into the machine >> image at $JOB for others to use. >> >> >> >>> >>> >>> >>>> On Tue, Jan 24, 2017 at 8:56 PM, Julian Elischer >>> > wrote: >>>> >>>> from he log file: (see below) >>>> >>>> This dies almost immediately. >>>> Do we need to prime the build with an older java? (e.g. the >>>> bootstrap pkg)? >>>> If so why does poudriere not do this? >>>> I actually want jdk8 but iti insists on building 7 first, which >>>> fails. >>>> Since I don't care about 7 I can prime the pump by downloading a >>>> 7 pkg but should all this be automatic somehow? >>>> >>>> Log: >>>> >>>> ######################################################################## >>>> >>>> ######################################################################## >>>> >>>> ##### Entering langtools for target(s) all ##### >>>> ######################################################################## >>>> >>>> >>>> (cd ./langtools/make && \ >>>> gmake >>>> JDK_TOPDIR=/wrkdirs/usr/ports/java/openjdk7/work/openjdk/jdk >>>> JDK_MAKE_SHARED_DIR=/wrkdirs/usr/ports/java/openjdk7/work/op >>>> enjdk/jdk/make/common/shared >>>> EXTERNALSANITYCONTROL=true SOURCE_LANGUAGE_VERSION=7 >>>> TARGET_CLASS_VERSION=7 MILESTONE=fcs BUILD_NUMBER=b01 >>>> JDK_BUILD_NUMBER=b01 FULL_VERSION=1.7.0_111-b01 >>>> PREVIOUS_JDK_VERSION=1.6. JDK_VERSION=1.7.0_111 >>>> JDK_MKTG_VERSION=7 JDK_MAJOR_VERSION=1 JDK_MINOR_VERSION=7 >>>> JDK_MICRO_VERSION=0_111 PREVIOUS_MAJOR_VERSION=1 >>>> PREVIOUS_MINOR_VERSION=6 PREVIOUS_MICRO_VERSION= >>>> PAX_COMMAND=/usr/sbin/paxmark.sh PAX_COMMAND_ARGS="-vm" >>>> ARCH_DATA_MODEL=64 COOKED_BUILD_NUMBER=1 >>>> ANT_HOME="/wrkdirs/usr/ports/java/openjdk7/work/apache-ant-1.9.7" >>>> ALT_OUTPUTDIR=/wrkdirs/usr/ports/java/openjdk7/work/openjdk/ >>>> build/bsd-amd64/langtools >>>> ALT_BOOTDIR=/usr/local/bootstrap-openjdk all) >>>> gmake[3]: Entering directory >>>> '/wrkdirs/usr/ports/java/openjdk7/work/openjdk/langtools/make' >>>> JAVA_HOME=/usr/local/bootstrap-openjdk >>>> ANT_OPTS=-Djava.io.tmpdir='/wrkdirs/usr/ports/java/openjdk7/ >>>> work/openjdk/build/bsd-amd64/langtools/build/ant-tmp' >>>> /wrkdirs/usr/ports/java/openjdk7/work/apache-ant-1.9.7/bin/ant >>>> -diagnostics > >>>> /wrkdirs/usr/ports/java/openjdk7/work/openjdk/build/bsd- >>>> amd64/langtools/build/ant-diagnostics.log >>>> ; \ >>>> JAVA_HOME=/usr/local/bootstrap-openjdk >>>> ANT_OPTS=-Djava.io.tmpdir='/wrkdirs/usr/ports/java/openjdk7/ >>>> work/openjdk/build/bsd-amd64/langtools/build/ant-tmp' >>>> /wrkdirs/usr/ports/java/openjdk7/work/apache-ant-1.9.7/bin/ant >>>> -version >> >>>> /wrkdirs/usr/ports/java/openjdk7/work/openjdk/build/bsd- >>>> amd64/langtools/build/ant-diagnostics.log >>>> Could not create the Java virtual machine. >>>> Could not create the Java virtual machine. >>>> gmake[3]: *** [Makefile:196: >>>> /wrkdirs/usr/ports/java/openjdk7/work/openjdk/build/bsd- >>>> amd64/langtools/build/ant-diagnostics.log] >>>> Error 1 >>>> gmake[3]: Leaving directory >>>> '/wrkdirs/usr/ports/java/openjdk7/work/openjdk/langtools/make' >>>> gmake[2]: *** [make/langtools-rules.gmk:39: langtools-build] Error 2 >>>> gmake[2]: Leaving directory >>>> '/wrkdirs/usr/ports/java/openjdk7/work/openjdk' >>>> gmake[1]: *** [Makefile:251: build_product_image] Error 2 >>>> gmake[1]: Leaving directory >>>> '/wrkdirs/usr/ports/java/openjdk7/work/openjdk' >>>> *** Error code 1 That sounds familiar. I seemed to recall having java problems on a machine that had a non-default datasize setting in /boot/loader.conf. I was able to work around it by setting some memory size knobs in an environment variable that java looks at. I think I did something like this: setenv _JAVA_OPTIONS -Xmx512m