lang/sun-jdk15 on amd64

[Milos Negovanovic]

Is anyone running lang/sun-jdk15 on amd64 successfully? I have it
installed but it core dumps immediately after running.

--
Milos Negovanovic
milos.negovanovic@...

[Kees Jan Koster]

Dear Milos.

> Is anyone running lang/sun-jdk15 on amd64 successfully? I have it
> installed but it core dumps immediately after running.


 From http://www.freebsd.org/java/dists/15.html

February 14, 2008: Greg Lewis has released the eighth patchset  
(patchlevel 8, "Tarragindi") for the JDK™ 1.5.0 software. This release  
now supports NetBSD/amd64 and the browser plugin runs on the amd64  
architecture. In addition, the source code base has been updated to  
1.5.0 Update 14. Information on downloading the patchset can be found  
at http://www.eyesbeyond.com/freebsddom/java/jdk15.html.

Perhaps you should have a chat with Greg? You can find him on the freebsd-java@...
  mailing lists. The Java porting effort for *bsd is concentrated on  
that list for historical reasons.
--
Kees Jan

http://java-monitor.com/forum/
kjkoster@...
06-51838192

Rule 1 for being in a hole: stop digging.

[Milos Negovanovic]

On Tue, Jan 13, 2009 at 02:12:44PM +0100, Kees Jan Koster wrote:

> Dear Milos.
>
>> Is anyone running lang/sun-jdk15 on amd64 successfully? I have it
>> installed but it core dumps immediately after running.
>
>
> From http://www.freebsd.org/java/dists/15.html
>
> February 14, 2008: Greg Lewis has released the eighth patchset  
> (patchlevel 8, "Tarragindi") for the JDK? 1.5.0 software. This release  
> now supports NetBSD/amd64 and the browser plugin runs on the amd64  
> architecture. In addition, the source code base has been updated to  
> 1.5.0 Update 14. Information on downloading the patchset can be found at
> http://www.eyesbeyond.com/freebsddom/java/jdk15.html.
>
> Perhaps you should have a chat with Greg? You can find him on the
> freebsd-java@... mailing lists. The Java porting effort for *bsd
> is concentrated on that list for historical reasons.

I am interested in running Linux java package via emulation, not the
native built java. This works just fine under i386.

--
Milos Negovanovic
milos.negovanovic@...

[Kees Jan Koster]

Dear Milos,

>>> Is anyone running lang/sun-jdk15 on amd64 successfully? I have it
>>> installed but it core dumps immediately after running.
>>
>>
>> From http://www.freebsd.org/java/dists/15.html
>>
>> February 14, 2008: Greg Lewis has released the eighth patchset
>> (patchlevel 8, "Tarragindi") for the JDK? 1.5.0 software. This  
>> release
>> now supports NetBSD/amd64 and the browser plugin runs on the amd64
>> architecture. In addition, the source code base has been updated to
>> 1.5.0 Update 14. Information on downloading the patchset can be  
>> found at
>> http://www.eyesbeyond.com/freebsddom/java/jdk15.html.
>>
>> Perhaps you should have a chat with Greg? You can find him on the
>> freebsd-java@... mailing lists. The Java porting effort for  
>> *bsd
>> is concentrated on that list for historical reasons.
>
> I am interested in running Linux java package via emulation, not the
> native built java. This works just fine under i386.

No idea, sorry. I always use the native build, because if I run into  
problems, they can be fixed by the Java porting team. The linux  
package is not open to such fixes.

--
Kees Jan

http://java-monitor.com/forum/
kjkoster@...
06-51838192

The secret of success lies in the stability of the goal. -- Benjamin  
Disraeli

[Milos Negovanovic]

On Tue, Jan 13, 2009 at 03:02:01PM +0100, Kees Jan Koster wrote:

> Dear Milos,
>
>>>> Is anyone running lang/sun-jdk15 on amd64 successfully? I have it
>>>> installed but it core dumps immediately after running.
>>>
>>>
>>> From http://www.freebsd.org/java/dists/15.html
>>>
>>> February 14, 2008: Greg Lewis has released the eighth patchset
>>> (patchlevel 8, "Tarragindi") for the JDK? 1.5.0 software. This  
>>> release
>>> now supports NetBSD/amd64 and the browser plugin runs on the amd64
>>> architecture. In addition, the source code base has been updated to
>>> 1.5.0 Update 14. Information on downloading the patchset can be  
>>> found at
>>> http://www.eyesbeyond.com/freebsddom/java/jdk15.html.
>>>
>>> Perhaps you should have a chat with Greg? You can find him on the
>>> freebsd-java@... mailing lists. The Java porting effort for  
>>> *bsd
>>> is concentrated on that list for historical reasons.
>>
>> I am interested in running Linux java package via emulation, not the
>> native built java. This works just fine under i386.
>
>
> No idea, sorry. I always use the native build, because if I run into  
> problems, they can be fixed by the Java porting team. The linux package
> is not open to such fixes.

How do you manage to build native jdk? It depends on linux emulated jdk
package (which core dumps for me).

--
Milos Negovanovic
milos.negovanovic@...

[Kees Jan Koster]

Dear Milos,

>> No idea, sorry. I always use the native build, because if I run into
>> problems, they can be fixed by the Java porting team. The linux  
>> package
>> is not open to such fixes.
>
> How do you manage to build native jdk? It depends on linux emulated  
> jdk
> package (which core dumps for me).


Hum. You ran into the bootstrap problem. Blech, I remember that one  
from way back when I hacked at the DEC Alpha port a little.  
Technically, building the JDK depends on any working JVM, not the  
linux one per se.

There are two paths for you to take; find a working JVM for your box  
and edit the port dependency so that it uses that JVM, or do the  
bootstrap on another machine.

I'm not sure what version of the JDK you need to bootstrap the JVM  
build.

First path speaks for itself, I think. Second path is more likely to  
work, but very fiddly. First run the build until it cores. Then see  
the last command that the build tried to run. That command is most  
likely "${your-bootstrap-java-home}/bin/javac ..." What you can do is  
copy the extracted and half-built JDK sources onto (say) a Linux/amd64  
system, then issue the failed command manually, then drag the half-
built tree back to the target machine and continue the build.

You can optimize this procedure if you study the command and its  
dependent files. I have done it in the past and it's not really as  
hard as it sounds.

This is all from memory, so please check with Greg Lewis and the java  
porting team on how to proceed. They know a lot more tricks than I do.
--
Kees Jan

http://java-monitor.com/forum/
kjkoster@...
06-51838192

The secret of success lies in the stability of the goal. -- Benjamin  
Disraeli

[Havard Eidnes-2]

> >> No idea, sorry. I always use the native build, because if I

> >> run into problems, they can be fixed by the Java porting
> >> team. The linux package is not open to such fixes.
> >
> > How do you manage to build native jdk? It depends on linux
> > emulated jdk package (which core dumps for me).
>
> Hum. You ran into the bootstrap problem. Blech, I remember that one  
> from way back when I hacked at the DEC Alpha port a little.  
> Technically, building the JDK depends on any working JVM, not the  
> linux one per se.
>
> There are two paths for you to take; find a working JVM for your box  
> and edit the port dependency so that it uses that JVM, or do the  
> bootstrap on another machine.

Actually, only a few java commands are needed to be run by
another java instance during the build.  The attached documents
how I went about getting a native jdk15 running for amd64.

It can be done, but it's a little quirky to set up.

Regards,

- Håvard

Return-Path: he@...
Delivery-Date: Wed, 14 Jan 2009 00:53:16 +0100
Return-Path: <he@...>
X-Original-To: he@...
Delivered-To: he@...
Received: from tyholt.uninett.no (tyholt.uninett.no [IPv6:2001:700:1::eecb])
        by smistad.uninett.no (Postfix) with ESMTP id 3F46C21DC43
        for <he@...>; Wed, 14 Jan 2009 00:53:16 +0100 (CET)
Received: from dike1b.uninett.no (dike1b.uninett.no [IPv6:2001:700:0:513::65])
        by tyholt.uninett.no (Postfix) with ESMTP id 3767E2BACAE
        for <he@...>; Wed, 14 Jan 2009 00:53:16 +0100 (CET)
X-Maildike-Whitelisted: Whitelisted client (global): 158.38.160.195
Received: from vestlia.uninett.no (vestlia.uninett.no [158.38.160.195])
        by dike1b.uninett.no (Postfix) with ESMTP id 2FC80A20064
        for <he@...>; Wed, 14 Jan 2009 00:53:16 +0100 (CET)
Received: from vestlia.uninett.no (localhost [127.0.0.1])
        by vestlia.uninett.no (Postfix) with ESMTP id 236E541A37
        for <he@...>; Wed, 14 Jan 2009 01:00:50 +0100 (CET)
Date: Fri, 01 Feb 2008 15:20:54 +0100 (CET)
Message-Id: <20080201.152054.104033544.he@...>
To: landonf@...
Cc: ltning@..., freebsd-java@...
Subject: Re: Sparc64
From: Havard Eidnes <he@...>
In-Reply-To: <BBFB1C9E-2679-4092-A483-B7B9BD55EBF0@...>
References: <6643EEC4-3DEE-479D-9EA1-F907CB31B345@...>
        <C4442CD9-D5D7-4E54-99FE-18061C6AA82B@...>
        <BBFB1C9E-2679-4092-A483-B7B9BD55EBF0@...>
X-Mailer: Mew version 5.2 on Emacs 21.4 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Multipart/Mixed;
 boundary="--Next_Part(Fri_Feb__1_15_20_54_2008_627)--"
Content-Transfer-Encoding: 7bit

----Next_Part(Fri_Feb__1_15_20_54_2008_627)--
Content-Type: Text/Plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

> What's the status of svr4 emulation on sparc64? I forgot a critical  =

> piece; One needs a bootstrap JVM, and bootstrapping off of Sun's VM  =

> would make things easier.

One can use a bootstrap JVM from another host (and architecture) and
some scripts which use ssh to the bootstrap host and sharing files via
NFS -- that's how I bootstrapped the NetBSD/amd64 version using the
NetBSD/i386 version.  I've attached my notes and the scripts I used to
do this.  (Admittedly, I've since tweaked the scripts to use
environment variables, so they've not been tested in their present
form...)

Best regards,

- H=E5vard

----Next_Part(Fri_Feb__1_15_20_54_2008_627)--
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

My notes for using a JVM on NetBSD/i386 to bootstrap JVM on
NetBSD/amd64:


I used a set of script wrappers which ssh to another machine (in my
case running NetBSD/i386, with its native java installed) which has
the same directory tree available via NFS as on the target (amd64)
machine, using the exact same paths.  Substitute scripts were made for
java, javac, javah, and jar, and the ALT_BOOTDIR was pointed to the
directory tree containing those scripts.  Some peculiarities were
discovered:

 o java needs to be able to read from stdin.  This means you
   can't use "ssh -n", which again means that the build job has
   to run in the foreground with access to the tty (yuk...).

 o javah gets at least once passed a class name with a $ in it.
   This causes issues because we get a double shell
   interpretation which leads to variable expansion; once on the
   local machine, once on the remote.  To work around that
   problem I borrowed the "shquote" shell function from pkgsrc
   and tweaked the argument list using it (it's included).

 o the jar script sleeps 10 seconds because otherwise it would
   trip over "stale NFS file handle" problems when some files
   were copied in place (replaced) on the NFS server just prior
   to using "jar".

Attached below is the set of scripts which I placed in /usr/pkg/java/
as boot-java/, packaged up as "boot-java.tar.gz".  Set JAVA_BOOTHOST
(your boot host) and JAVA_BOOTDIR (top of java directory tree on
JAVA_BOOTHOST) in the environment to suit your config.  I also include
the "build-java" shell script I used (to be executed from the top of
the Java source tree).

----Next_Part(Fri_Feb__1_15_20_54_2008_627)--
Content-Type: Application/Octet-Stream
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="boot-java.tar.gz"

H4sIABgqo0cAA+2a207bQBCGuY2fYutYmERKvD5LTUNLVVVtb5AoqpBYSJzY4ACNqTehFxCevWs7
do7kABvTNvNJ8WFtz2w8/me8m7SCoFe5cu6cnc2BsYFt02RrrNomHl+n7KjYVm3LtDVss3YVG6a+
Y26wTxl92nNChHZ8b/F5y47/o7TS+CutTndDPlaMv4ktzcRYi+KvatiA+OfARPyVaKPN3QeT88L4
a+zYMP5Gcp6q6Sp7Drj3ZA5bHv/iGxRHnvqC4Nabt7/dpuC1/QBR6qNKF0n33w5+HDQ+Hh4efzn8
fjxARCjIbRfJkivX2HJ0+NPXo4E8eoqQjETpg4j2dzWBky3htW/Wf8is/n3uPpbp39Cskf4NFfSf
I+P6ryKlT0Pl9vpSSZ6I7NmgfuWm06pGJ10EIXJQpxsrsobcQChQ/1c/6HmsxRGFghNe0jrbZCsk
DQ+5ouAGXY9vivHjtBD54ZJlxsxtUaKZ1T9/H0vrvzFW/20c6181dNB/Diys/8+V0nTtf6GdLZJj
7kzrP9yAj2X617E5M/6zLQz6zwH0dAK48bxbpOJExcMdDoU75DYyCCE/vJg54/9H3j6W1n9LT/Wv
W6oe13/2IgD6z4G1x/8jWU4OFq7c64paNat4vSmA9c2B2nkyU/+5q3+F+q9l87+6aWvJ+79lgv5z
YGPlf7Gc138JWM0eJIc1ma3//BPA8vn/sfqf/P6n6boF+s+B9cb/q1frpVMAa5sCaW+COfP/ub//
G7ox0r+WvP+bGOp/HvyN8/+rp4ZVfwJ4lsWtSDhzYszdR6R/yzCe0r9q6Fb2/x/TTOb/NQPqfx4U
0ecw+ImYImjYFoQiF4QiSnMCUxLbSzjyev2wS1n6aDnta3rjUN9zkdN1UZIk0J0X0k7QRcFFdF2U
ZLIEUuXVtaHBvZJwLwz7hd6yjBFlpHq0GEw0U8+ts89AyFobzEKDda8uqZNt0amixJao4iGVKucn
iiLOnNKI3Tdov0V7dZkqZO+UNIkoEXJGSgohRFUu5eyqtkM9JKUu2R3JjpTjy0h0XbmUtaakt63e
lOJUK55kRkT0MLQ47Koozeub2JwxWquNvC9wKY5cLTLhUac99T1TE1Pf85Q8kiI5J7ukTPZIidyT
AXkgNfKO7JP3RCaIFM7KD2X2EcVF/WJ3Od0h4vK+sZi/tjoBAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAYD5/AAOW0OwAUAAA

----Next_Part(Fri_Feb__1_15_20_54_2008_627)--
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline; filename=build-java

#!/usr/bin/env bash

set -x

export MAKE_VERBOSE=t

unset LANG
unset JAVA_HOME
unset CLASSPATH
unset LD_LIBRARY_PATH
export ALT_MOTIF_DIR=/usr/pkg
# export ALT_NSPR_PATH=/usr/pkg
export ALT_NSPR_HEADERS_PATH=/usr/pkg/include/firefox/nspr
export ALT_MOZILLA_HEADERS_PATH=/usr/pkg/include/firefox
export SKIP_COMPARE_IMAGES=YES
export DONT_ENABLE_IPV6=YES
export ALT_BOOTDIR=/usr/pkg/java/boot-java
# export ALT_BOOTDIR=/usr/pkg/java/jdk-1.5.0
# export ALT_BOOTDIR=/usr/pkg/java/sun-1.5

cd control/make/
gmake

----Next_Part(Fri_Feb__1_15_20_54_2008_627)----

[Havard Eidnes-2]

[[ re-posted with the correct MIME body type for the attachment
   -- sorry! ]]

> >> No idea, sorry. I always use the native build, because if I
> >> run into problems, they can be fixed by the Java porting
> >> team. The linux package is not open to such fixes.
> >
> > How do you manage to build native jdk? It depends on linux
> > emulated jdk package (which core dumps for me).
>
> Hum. You ran into the bootstrap problem. Blech, I remember that one  
> from way back when I hacked at the DEC Alpha port a little.  
> Technically, building the JDK depends on any working JVM, not the  
> linux one per se.
>
> There are two paths for you to take; find a working JVM for your box  
> and edit the port dependency so that it uses that JVM, or do the  
> bootstrap on another machine.

Actually, only a few java commands are needed to be run by
another java instance during the build.  The attached documents
how I went about getting a native jdk15 running for amd64.

It can be done, but it's a little quirky to set up.

Regards,

- Håvard

> What's the status of svr4 emulation on sparc64? I forgot a critical  
> piece; One needs a bootstrap JVM, and bootstrapping off of Sun's VM  
> would make things easier.

One can use a bootstrap JVM from another host (and architecture) and
some scripts which use ssh to the bootstrap host and sharing files via
NFS -- that's how I bootstrapped the NetBSD/amd64 version using the
NetBSD/i386 version.  I've attached my notes and the scripts I used to
do this.  (Admittedly, I've since tweaked the scripts to use
environment variables, so they've not been tested in their present
form...)

Best regards,

- Håvard

My notes for using a JVM on NetBSD/i386 to bootstrap JVM on
NetBSD/amd64:


I used a set of script wrappers which ssh to another machine (in my
case running NetBSD/i386, with its native java installed) which has
the same directory tree available via NFS as on the target (amd64)
machine, using the exact same paths.  Substitute scripts were made for
java, javac, javah, and jar, and the ALT_BOOTDIR was pointed to the
directory tree containing those scripts.  Some peculiarities were
discovered:

 o java needs to be able to read from stdin.  This means you
   can't use "ssh -n", which again means that the build job has
   to run in the foreground with access to the tty (yuk...).

 o javah gets at least once passed a class name with a $ in it.
   This causes issues because we get a double shell
   interpretation which leads to variable expansion; once on the
   local machine, once on the remote.  To work around that
   problem I borrowed the "shquote" shell function from pkgsrc
   and tweaked the argument list using it (it's included).

 o the jar script sleeps 10 seconds because otherwise it would
   trip over "stale NFS file handle" problems when some files
   were copied in place (replaced) on the NFS server just prior
   to using "jar".

Attached below is the set of scripts which I placed in /usr/pkg/java/
as boot-java/, packaged up as "boot-java.tar.gz".  Set JAVA_BOOTHOST
(your boot host) and JAVA_BOOTDIR (top of java directory tree on
JAVA_BOOTHOST) in the environment to suit your config.  I also include
the "build-java" shell script I used (to be executed from the top of
the Java source tree).


#!/usr/bin/env bash

set -x

export MAKE_VERBOSE=t

unset LANG
unset JAVA_HOME
unset CLASSPATH
unset LD_LIBRARY_PATH
export ALT_MOTIF_DIR=/usr/pkg
# export ALT_NSPR_PATH=/usr/pkg
export ALT_NSPR_HEADERS_PATH=/usr/pkg/include/firefox/nspr
export ALT_MOZILLA_HEADERS_PATH=/usr/pkg/include/firefox
export SKIP_COMPARE_IMAGES=YES
export DONT_ENABLE_IPV6=YES
export ALT_BOOTDIR=/usr/pkg/java/boot-java
# export ALT_BOOTDIR=/usr/pkg/java/jdk-1.5.0
# export ALT_BOOTDIR=/usr/pkg/java/sun-1.5

cd control/make/
gmake

[Geert Hendrickx]

Hi Håvard,

any idea why the same procedure wouldn't work with the native 32-bit JDK
running on the target amd64 host itself, using COMPAT_NETBSD32?  I'm trying
to do that (I built the native JDK on NetBSD/i386 and installed it on my
NetBSD/amd64 host), but running the 32-bit java binary gives the following:

 28531      1 java     netbsd32_mmap(0, 0x43e00000, 0, 0x1042, 0xffffffffffffffff, 0, 0, 0) Err#12 ENOMEM

Error occurred during initialization of VM
Could not reserve enough space for object heap
Could not create the Java virtual machine.

I bumped datasize and stacksize limits to very high values but no luck.

        Geert



On Wed, Jan 14, 2009 at 01:44:57AM +0100, Havard Eidnes wrote:

> [[ re-posted with the correct MIME body type for the attachment
>    -- sorry! ]]
>
> > >> No idea, sorry. I always use the native build, because if I
> > >> run into problems, they can be fixed by the Java porting
> > >> team. The linux package is not open to such fixes.
> > >
> > > How do you manage to build native jdk? It depends on linux
> > > emulated jdk package (which core dumps for me).
> >
> > Hum. You ran into the bootstrap problem. Blech, I remember that one  
> > from way back when I hacked at the DEC Alpha port a little.  
> > Technically, building the JDK depends on any working JVM, not the  
> > linux one per se.
> >
> > There are two paths for you to take; find a working JVM for your box  
> > and edit the port dependency so that it uses that JVM, or do the  
> > bootstrap on another machine.
>
> Actually, only a few java commands are needed to be run by
> another java instance during the build.  The attached documents
> how I went about getting a native jdk15 running for amd64.
>
> It can be done, but it's a little quirky to set up.
>
> Regards,
>
> - Håvard

[Havard Eidnes-2]

> any idea why the same procedure wouldn't work with the native 32-bit JDK
> running on the target amd64 host itself, using COMPAT_NETBSD32?

I was told at the time that there are apparent hard-to-find bugs
in our Linux emulation which prevents this from working, so to
save myself from grief others have already experienced, I did not
pursue that avenue any further.

> I'm trying to do that (I built the native JDK on NetBSD/i386
> and installed it on my NetBSD/amd64 host), but running the
> 32-bit java binary gives the following:
>
>  28531      1 java     netbsd32_mmap(0, 0x43e00000, 0, 0x1042, 0xffffffffffffffff, 0, 0, 0) Err#12 ENOMEM
>
> Error occurred during initialization of VM
> Could not reserve enough space for object heap
> Could not create the Java virtual machine.

Sounds like a possible sign extension problem in combination with
a 32/64-bit confusion, perhaps?  I'm just guessing...

Regards,

- Håvard

[Arto Huusko-2]

> Is anyone running lang/sun-jdk15 on amd64 successfully? I have it
> installed but it core dumps immediately after running.

Hi,

what version of NetBSD is this? There are a number of issues:

 - 64-bit Linux java won't work, for some reason. I never investigated
   further, because I was able to get 32-bit working.

 - Some bugs in linux32 emulation that affected java have been          
   fixed during the last year in NetBSD-current, while some others
   remain. Most notably kern/37437.

So if you have NetBSD 4 or old -current, try to update. On -current, try
the patch in kern/37437, it should make things go.

I have jdk 1.6.0_10 relatively stable on 5.99.3 with the patch, but it does
get SEGV occasionally (which did not happen on 4.99.73).

[Milos Negovanovic]

On Thu, Jan 15, 2009 at 03:18:38PM +0200, Arto Huusko wrote:
> > Is anyone running lang/sun-jdk15 on amd64 successfully? I have it
> > installed but it core dumps immediately after running.
>
> Hi,
>
> what version of NetBSD is this? There are a number of issues:

Its 5 BETA amd64

>
>  - 64-bit Linux java won't work, for some reason. I never investigated
>    further, because I was able to get 32-bit working.

How did you manage to install 32bit java? pkgsrc by default installs
amd64 linux binaries.

>
>  - Some bugs in linux32 emulation that affected java have been
>    fixed during the last year in NetBSD-current, while some others
>    remain. Most notably kern/37437.
>
> So if you have NetBSD 4 or old -current, try to update. On -current,
> try
> the patch in kern/37437, it should make things go.

Its 5 BETA amd64.

>
> I have jdk 1.6.0_10 relatively stable on 5.99.3 with the patch, but it
> does
> get SEGV occasionally (which did not happen on 4.99.73).


--
Milos Negovanovic
milos.negovanovic@...