Nabble - netbsd-java

Re: Problem with Nimbus in openjdk7

2009-10-24T05:27:53Z

On Fri, Oct 23, 2009 at 8:03 PM, Adam Hoka <ahoka@...> wrote:

> Hi!
>
> I'm using openjdk7 from pkgsrc as of today's sources, and
> it runs Netbeans very well, but i run into problems when i want to
> switch to the Nimbus look'n'feel:
>
> $ /opt/jedit/bin/jedit
> 1:56:51 AM [main] [error] jEdit: java.lang.NullPointerException
> 1:56:51 AM [main] [error] jEdit: at sun.font.FontManager.getFontConfigFont(FontManager.java:3481)
> 1:56:51 AM [main] [error] jEdit: at sun.font.FontManager.getFontConfigFUIR(FontManager.java:3601)
> 1:56:51 AM [main] [error] jEdit: at javax.swing.plaf.nimbus.NimbusDefaults.<init>(NimbusDefaults.java:134)
> 1:56:51 AM [main] [error] jEdit: at javax.swing.plaf.nimbus.NimbusLookAndFeel.<init>(NimbusLookAndFeel.java:100)
> 1:56:51 AM [main] [error] jEdit: at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> 1:56:51 AM [main] [error] jEdit: at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
> 1:56:51 AM [main] [error] jEdit: at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> 1:56:51 AM [main] [error] jEdit: at java.lang.reflect.Constructor.newInstance(Constructor.java:535)
> 1:56:51 AM [main] [error] jEdit: at java.lang.Class.newInstance0(Class.java:372)
> 1:56:51 AM [main] [error] jEdit: at java.lang.Class.newInstance(Class.java:325)
> 1:56:51 AM [main] [error] jEdit: at javax.swing.UIManager.setLookAndFeel(UIManager.java:593)
> 1:56:51 AM [main] [error] jEdit: at org.gjt.sp.jedit.jEdit.initPLAF(jEdit.java:3568)
> 1:56:51 AM [main] [error] jEdit: at org.gjt.sp.jedit.jEdit.main(jEdit.java:438)
>
> The test application was jedit as it allows setting theme from a menu, bu i cant get working it with Netbeans
> or anything else either.
>
> Looking at the code it seems that something doesnt get initialized, but I couldnt find
> the code for the initialization itself.
>
> Any ideas?

Is there any more to that stack trace? (a "cached by", for example?)

I also found some pretty recent threads about nimbus on the openjdk
site mentioning that it was still a target milstone for import and
that it had been imported as binary and then removed for lack of
sources, so I'm not confident in the current state.

I will have to try it on a remote jconsole to see if it saves any
bandwidth, though. :)

Problem with Nimbus in openjdk7

2009-10-23T17:03:10Z

Hi!

I'm using openjdk7 from pkgsrc as of today's sources, and
it runs Netbeans very well, but i run into problems when i want to
switch to the Nimbus look'n'feel:

$ /opt/jedit/bin/jedit
1:56:51 AM [main] [error] jEdit: java.lang.NullPointerException
1:56:51 AM [main] [error] jEdit: at sun.font.FontManager.getFontConfigFont(FontManager.java:3481)
1:56:51 AM [main] [error] jEdit: at sun.font.FontManager.getFontConfigFUIR(FontManager.java:3601)
1:56:51 AM [main] [error] jEdit: at javax.swing.plaf.nimbus.NimbusDefaults.<init>(NimbusDefaults.java:134)
1:56:51 AM [main] [error] jEdit: at javax.swing.plaf.nimbus.NimbusLookAndFeel.<init>(NimbusLookAndFeel.java:100)
1:56:51 AM [main] [error] jEdit: at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
1:56:51 AM [main] [error] jEdit: at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
1:56:51 AM [main] [error] jEdit: at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
1:56:51 AM [main] [error] jEdit: at java.lang.reflect.Constructor.newInstance(Constructor.java:535)
1:56:51 AM [main] [error] jEdit: at java.lang.Class.newInstance0(Class.java:372)
1:56:51 AM [main] [error] jEdit: at java.lang.Class.newInstance(Class.java:325)
1:56:51 AM [main] [error] jEdit: at javax.swing.UIManager.setLookAndFeel(UIManager.java:593)
1:56:51 AM [main] [error] jEdit: at org.gjt.sp.jedit.jEdit.initPLAF(jEdit.java:3568)
1:56:51 AM [main] [error] jEdit: at org.gjt.sp.jedit.jEdit.main(jEdit.java:438)

The test application was jedit as it allows setting theme from a menu, bu i cant get working it with Netbeans
or anything else either.

Looking at the code it seems that something doesnt get initialized, but I couldnt find
the code for the initialization itself.

Any ideas?

Re: openjdk7 in pkgsrc

2009-10-21T07:13:09Z

(cross-posting to tech-pkg@)

On Wed, Oct 14, 2009 at 05:38:30PM +0200, Geert Hendrickx wrote:

(this has been fixed now)

> But then it fails with:
>
> checking for XP... no
> configure: error: Could not find Xp - Try installing libXp-devel.
> *** Error code 1
>
> Although the buildlink wrappers are there...

The buildlink wrapper for xp.pc is missing. It works when I manually
symlink it in the work directory. This should really be fixed in the
pkgtools/x11-links package but I'm missing clue here...

Can anyone fix x11-links to include the pkg-config file for libXp?

Geert

--
Geert Hendrickx -=- ghen@... -=- PGP: 0xC4BB9E9F
This e-mail was composed using 100% recycled spam messages!

Re: openjdk7 in pkgsrc

2009-10-21T06:59:15Z

On Wed, Oct 21, 2009 at 6:17 AM, Geert Hendrickx <ghen@...> wrote:

> On Wed, Oct 21, 2009 at 11:56:52AM +0200, Tobias Nygren wrote:
>> On Wed, 21 Oct 2009 11:38:07 +0200, Geert Hendrickx <ghen@...> wrote:
>> > I'm not sure whether we should explicitly depend on the used fonts though.
>> > I've added a dependency on DejaVu (covers a lot of scripts, including
>> > Latin) and a commented one on ja-sazanami-ttf (Japanese) and baekmuk-ttf
>> > (Korean). The Chinese fonts are not in pkgsrc and I have no idea which
>> > could replace them. :-)
>>
>> Do we need to distinguish between native / modular X.org or do anything
>> special for base fonts? Also, while there, feel free to improve patch-ap
>> (I doubt it's correct). If mind serves me correctly it was inherited from
>> wip/jdk16.
>
>
> DejaVu fonts are only in pkgsrc, so that's easy.
>
> I was thinking to just use Vera fonts from base instead (to get rid of the
> dependency), but then indeed we need to worry about native X vs. pkgsrc X,
> and the fonts/vera-ttf package does not have a builtin.mk to facilitate
> this, so for now I just won't bother and use DejaVu instead.
>
> For patch-ap, I'll substitute %%PREFIX%% there as well.
>

All very good news!

Re: openjdk7 in pkgsrc

2009-10-21T03:17:26Z

On Wed, Oct 21, 2009 at 11:56:52AM +0200, Tobias Nygren wrote:

> On Wed, 21 Oct 2009 11:38:07 +0200, Geert Hendrickx <ghen@...> wrote:
> > I'm not sure whether we should explicitly depend on the used fonts though.
> > I've added a dependency on DejaVu (covers a lot of scripts, including
> > Latin) and a commented one on ja-sazanami-ttf (Japanese) and baekmuk-ttf
> > (Korean). The Chinese fonts are not in pkgsrc and I have no idea which
> > could replace them. :-)
>
> Do we need to distinguish between native / modular X.org or do anything
> special for base fonts? Also, while there, feel free to improve patch-ap
> (I doubt it's correct). If mind serves me correctly it was inherited from
> wip/jdk16.

DejaVu fonts are only in pkgsrc, so that's easy.

I was thinking to just use Vera fonts from base instead (to get rid of the
dependency), but then indeed we need to worry about native X vs. pkgsrc X,
and the fonts/vera-ttf package does not have a builtin.mk to facilitate
this, so for now I just won't bother and use DejaVu instead.

For patch-ap, I'll substitute %%PREFIX%% there as well.

Geert

--
Geert Hendrickx -=- ghen@... -=- PGP: 0xC4BB9E9F
This e-mail was composed using 100% recycled spam messages!

Re: openjdk7 in pkgsrc

2009-10-21T02:56:52Z

On Wed, 21 Oct 2009 11:38:07 +0200
Geert Hendrickx <ghen@...> wrote:

> We're using bsd.fontconfig.properties which is apparantly (mostly) just a
> copy of linux.fontconfig.Fedora.properties. The attached patch fixes it,
> ok to commit?

Yes, please.

> I'm not sure whether we should explicitly depend on the used fonts though.
> I've added a dependency on DejaVu (covers a lot of scripts, including
> Latin) and a commented one on ja-sazanami-ttf (Japanese) and baekmuk-ttf
> (Korean). The Chinese fonts are not in pkgsrc and I have no idea which
> could replace them. :-)

Do we need to distinguish between native / modular X.org or do anything
special for base fonts? Also, while there, feel free to improve
patch-ap (I doubt it's correct). If mind serves me correctly it was
inherited from wip/jdk16.

Re: openjdk7 in pkgsrc

2009-10-21T02:38:07Z

On Wed, Oct 21, 2009 at 10:01:55AM +0200, Tobias Nygren wrote:

> On Wed, 21 Oct 2009 08:09:25 +0200
> Geert Hendrickx <ghen@...> wrote:
>
> > On Tue, Oct 20, 2009 at 05:35:47PM -0400, matthew sporleder wrote:
> > > Java should have a fontdir set and by default tends to look at x font
> > > server or in some standard locations like /usr/share/fonts/font
> > > (something like that). You are probably just seeing the six default awt
> > > fonts. Check out java_home/jre/lib for more font stuff in java.
> > >
> > > Pkgsrc could create a new font config file to look in pkgdirs, but I
> > > think the binary format is proprietary or something.
> >
> >
> > Interestingly, the 1.5/1.6 JDK's ship their own fonts under jre/lib/fonts/
> > (Lucida* fonts) while openjdk7 doesn't. It has a fontconfig.properties.src
> > file which is configured with DejaVu instead, and refers to absolute font
> > paths (for Fedora Core 6 according to a comment in the file). Changing the
> > paths there doesn't help, I guess the binary fontconfig.bfc must somehow be
> > regenerated from it.
>
> Indeed, the ugly looking fonts are a known problem. You can probably
> remove the .bfc file and put a .properties there instead, but I'm not
> sure.
>
> If you "make extract" in openjdk7, then some clues may be found in:
> ${WRKDIR}/icedtea-175529fae103/patches/icedtea-fonts.patch It's an update
> to the font configuration from FC6 to FC9 according to the comment. I
> guess we need something similar.

We're using bsd.fontconfig.properties which is apparantly (mostly) just a
copy of linux.fontconfig.Fedora.properties. The attached patch fixes it,
ok to commit?

I'm not sure whether we should explicitly depend on the used fonts though.
I've added a dependency on DejaVu (covers a lot of scripts, including
Latin) and a commented one on ja-sazanami-ttf (Japanese) and baekmuk-ttf
(Korean). The Chinese fonts are not in pkgsrc and I have no idea which
could replace them. :-)

Geert

--
Geert Hendrickx -=- ghen@... -=- PGP: 0xC4BB9E9F
This e-mail was composed using 100% recycled spam messages!

Index: Makefile
===================================================================
RCS file: /cvsroot/pkgsrc/lang/openjdk7/Makefile,v
retrieving revision 1.4
diff -u -r1.4 Makefile
--- Makefile 18 Oct 2009 12:30:54 -0000 1.4
+++ Makefile 21 Oct 2009 09:33:43 -0000
@@ -35,6 +35,10 @@
MAKE_ENV+= PKGSRC_UNZIP=${PREFIX}/bin/unzip
MAKE_ENV+= PKGSRC_UNZIPSFX=${PREFIX}/bin/unzipsfv

+DEPENDS+= dejavu-ttf-[0-9]*:../../fonts/dejavu-ttf
+#DEPENDS+= ja-sazanami-ttf-[0-9]*:../../fonts/ja-sazanami-ttf
+#DEPENDS+= baekmuk-ttf-[0-9]*:../../fonts/baekmuk-ttf
+
NO_CONFIGURE= yes
USE_LANGUAGES= c c++
USE_TOOLS+= gmake pax
@@ -78,6 +82,12 @@
jdk/make/sun/xawt/Makefile
SUBST_SED.add-rpaths= -e 's|-L$$(OPENWIN_LIB)|-L$$(OPENWIN_LIB) -Wl,-R$$(OPENWIN_LIB)|g'

+SUBST_CLASSES+= fontpaths
+SUBST_STAGE.fontpaths= pre-build
+SUBST_MESSAGE.fontpaths= fixing font paths
+SUBST_FILES.fontpaths= jdk/src/solaris/classes/sun/awt/fontconfigs/bsd.fontconfig.properties
+SUBST_SED.fontpaths= -e 's|%%PREFIX%%|${PREFIX}|'
+
PLIST_VARS+= i386
.if ${MACHINE_ARCH} == "i386"
PLIST.i386= yes
Index: distinfo
===================================================================
RCS file: /cvsroot/pkgsrc/lang/openjdk7/distinfo,v
retrieving revision 1.2
diff -u -r1.2 distinfo
--- distinfo 18 Oct 2009 10:21:01 -0000 1.2
+++ distinfo 21 Oct 2009 09:33:43 -0000
@@ -72,3 +72,4 @@
SHA1 (patch-bk) = 66bccfdf42fcc6f6995f3f18fc2515d55cab46c6
SHA1 (patch-bl) = a3b3bd6007c83664538baf401447fd0df9f4143b
SHA1 (patch-bm) = 40c83ad219f529c3ca130547560681ab57b44bf8
+SHA1 (patch-bn) = 571d98951cc2a53dd1512e7f7d4495381e1c4004
Index: patches/patch-bn
===================================================================
RCS file: patches/patch-bn
diff -N patches/patch-bn
--- /dev/null 1 Jan 1970 00:00:00 -0000
+++ patches/patch-bn 21 Oct 2009 09:33:43 -0000
@@ -0,0 +1,47 @@
+$NetBSD$
+
+--- jdk/src/solaris/classes/sun/awt/fontconfigs/bsd.fontconfig.properties.orig 2009-10-21 11:09:00.000000000 +0200
++++ jdk/src/solaris/classes/sun/awt/fontconfigs/bsd.fontconfig.properties
+@@ -166,24 +166,24 @@ sequence.fallback=chinese-big5,chinese-g
+
+ # Font File Names
+
+-filename.DejaVu_LGC_Sans=/usr/share/fonts/dejavu-lgc/DejaVuLGCSans.ttf
+-filename.DejaVu_LGC_Sans_Bold=/usr/share/fonts/dejavu-lgc/DejaVuLGCSans-Bold.ttf
+-filename.DejaVu_LGC_Sans_Oblique=/usr/share/fonts/dejavu-lgc/DejaVuLGCSans-Oblique.ttf
+-filename.DejaVu_LGC_Sans_Bold_Oblique=/usr/share/fonts/dejavu-lgc/DejaVuLGCSans-BoldOblique.ttf
++filename.DejaVu_LGC_Sans=%%PREFIX%%/lib/X11/fonts/TTF/DejaVuSans.ttf
++filename.DejaVu_LGC_Sans_Bold=%%PREFIX%%/lib/X11/fonts/TTF/DejaVuSans-Bold.ttf
++filename.DejaVu_LGC_Sans_Oblique=%%PREFIX%%/lib/X11/fonts/TTF/DejaVuSans-Oblique.ttf
++filename.DejaVu_LGC_Sans_Bold_Oblique=%%PREFIX%%/lib/X11/fonts/TTF/DejaVuSans-BoldOblique.ttf
+
+-filename.DejaVu_LGC_Sans_Mono=/usr/share/fonts/dejavu-lgc/DejaVuLGCSansMono.ttf
+-filename.DejaVu_LGC_Sans_Mono_Bold=/usr/share/fonts/dejavu-lgc/DejaVuLGCSansMono-Bold.ttf
+-filename.DejaVu_LGC_Sans_Mono_Oblique=/usr/share/fonts/dejavu-lgc/DejaVuLGCSansMono-Oblique.ttf
+-filename.DejaVu_LGC_Sans_Mono_Bold_Oblique=/usr/share/fonts/dejavu-lgc/DejaVuLGCSansMono-BoldOblique.ttf
++filename.DejaVu_LGC_Sans_Mono=%%PREFIX%%/lib/X11/fonts/TTF/DejaVuSansMono.ttf
++filename.DejaVu_LGC_Sans_Mono_Bold=%%PREFIX%%/lib/X11/fonts/TTF/DejaVuSansMono-Bold.ttf
++filename.DejaVu_LGC_Sans_Mono_Oblique=%%PREFIX%%/lib/X11/fonts/TTF/DejaVuSansMono-Oblique.ttf
++filename.DejaVu_LGC_Sans_Mono_Bold_Oblique=%%PREFIX%%/lib/X11/fonts/TTF/DejaVuSansMono-BoldOblique.ttf
+
+-filename.DejaVu_LGC_Serif=/usr/share/fonts/dejavu-lgc/DejaVuLGCSerif.ttf
+-filename.DejaVu_LGC_Serif_Bold=/usr/share/fonts/dejavu-lgc/DejaVuLGCSerif-Bold.ttf
+-filename.DejaVu_LGC_Serif_Oblique=/usr/share/fonts/dejavu-lgc/DejaVuLGCSerif-Oblique.ttf
+-filename.DejaVu_LGC_Serif_Bold_Oblique=/usr/share/fonts/dejavu-lgc/DejaVuLGCSerif-BoldOblique.ttf
++filename.DejaVu_LGC_Serif=%%PREFIX%%/lib/X11/fonts/TTF/DejaVuSerif.ttf
++filename.DejaVu_LGC_Serif_Bold=%%PREFIX%%/lib/X11/fonts/TTF/DejaVuSerif-Bold.ttf
++filename.DejaVu_LGC_Serif_Oblique=%%PREFIX%%/lib/X11/fonts/TTF/DejaVuSerif-Italic.ttf
++filename.DejaVu_LGC_Serif_Bold_Oblique=%%PREFIX%%/lib/X11/fonts/TTF/DejaVuSerif-BoldItalic.ttf
+
+-filename.Sazanami_Gothic=/usr/share/fonts/japanese/TrueType/sazanami-gothic.ttf
+-filename.Sazanami_Mincho=/usr/share/fonts/japanese/TrueType/sazanami-mincho.ttf
+-filename.AR_PL_ShanHeiSun_Uni=/usr/share/fonts/chinese/TrueType/uming.ttf
+-filename.AR_PL_ZenKai_Uni=/usr/share/fonts/chinese/TrueType/ukai.ttf
+-filename.Baekmuk_Gulim=/usr/share/fonts/korean/TrueType/gulim.ttf
+-filename.Baekmuk_Batang=/usr/share/fonts/korean/TrueType/batang.ttf
++filename.Sazanami_Gothic=%%PREFIX%%/lib/X11/fonts/TTF/sazanami-gothic.ttf
++filename.Sazanami_Mincho=%%PREFIX%%/lib/X11/fonts/TTF/sazanami-mincho.ttf
++filename.AR_PL_ShanHeiSun_Uni=%%PREFIX%%/lib/X11/fonts/TTF/uming.ttf
++filename.AR_PL_ZenKai_Uni=%%PREFIX%%/lib/X11/fonts/TTF/ukai.ttf
++filename.Baekmuk_Gulim=%%PREFIX%%/lib/X11/fonts/TTF/gulim.ttf
++filename.Baekmuk_Batang=%%PREFIX%%/lib/X11/fonts/TTF/batang.ttf

attachment0 (498 bytes) Download Attachment

Re: openjdk7 in pkgsrc

2009-10-21T01:01:55Z

On Wed, 21 Oct 2009 08:09:25 +0200
Geert Hendrickx <ghen@...> wrote:

> On Tue, Oct 20, 2009 at 05:35:47PM -0400, matthew sporleder wrote:
> > Java should have a fontdir set and by default tends to look at x font
> > server or in some standard locations like /usr/share/fonts/font
> > (something like that). You are probably just seeing the six default awt
> > fonts. Check out java_home/jre/lib for more font stuff in java.
> >
> > Pkgsrc could create a new font config file to look in pkgdirs, but I
> > think the binary format is proprietary or something.
>
>
> Interestingly, the 1.5/1.6 JDK's ship their own fonts under jre/lib/fonts/
> (Lucida* fonts) while openjdk7 doesn't. It has a fontconfig.properties.src
> file which is configured with DejaVu instead, and refers to absolute font
> paths (for Fedora Core 6 according to a comment in the file). Changing the
> paths there doesn't help, I guess the binary fontconfig.bfc must somehow be
> regenerated from it.

Indeed, the ugly looking fonts are a known problem. You can probably
remove the .bfc file and put a .properties there instead, but I'm not
sure.

If you "make extract" in openjdk7, then some clues may be found in:
${WRKDIR}/icedtea-175529fae103/patches/icedtea-fonts.patch
It's an update to the font configuration from FC6 to FC9 according to
the comment. I guess we need something similar.

-Tobias

Re: openjdk7 in pkgsrc

2009-10-20T23:09:25Z

On Tue, Oct 20, 2009 at 05:35:47PM -0400, matthew sporleder wrote:
> Java should have a fontdir set and by default tends to look at x font
> server or in some standard locations like /usr/share/fonts/font
> (something like that). You are probably just seeing the six default awt
> fonts. Check out java_home/jre/lib for more font stuff in java.
>
> Pkgsrc could create a new font config file to look in pkgdirs, but I
> think the binary format is proprietary or something.

Interestingly, the 1.5/1.6 JDK's ship their own fonts under jre/lib/fonts/
(Lucida* fonts) while openjdk7 doesn't. It has a fontconfig.properties.src
file which is configured with DejaVu instead, and refers to absolute font
paths (for Fedora Core 6 according to a comment in the file). Changing the
paths there doesn't help, I guess the binary fontconfig.bfc must somehow be
regenerated from it.

I'll have a look at how we can fix these paths in the pkgsrc package so
fontconfig.bfc is generated with the correct paths from the first time. We
then probably need additional dependencies on the fonts themselves too
(mostly DejaVu, plus some additional CJK fonts which should probably be
added as optional dependencies, or just have their paths corrected without
an explicit dependency).

Geert

--
Geert Hendrickx -=- ghen@... -=- PGP: 0xC4BB9E9F
This e-mail was composed using 100% recycled spam messages!

Re: openjdk7 in pkgsrc

2009-10-20T14:35:47Z

Java should have a fontdir set and by default tends to look at x font
server or in some standard locations like /usr/share/fonts/font
(something like that). You are probably just seeing the six default
awt fonts. Check out java_home/jre/lib for more font stuff in java.

Pkgsrc could create a new font config file to look in pkgdirs, but I
think the binary format is proprietary or something.

On 10/20/09, Geert Hendrickx <ghen@...> wrote:

> On Wed, Oct 14, 2009 at 03:26:31PM +0200, Tobias Nygren wrote:
>> Hi,
>>
>> I've imported an experimental source-based JDK package to
>> pkgsrc/lang/openjdk7. Feel free to test and to contribute fixes.
>> It should build on NetBSD>=5 i386 and amd64, native and modular
>> X.org. Support for Linux and DragonFlyBSD will be added soon.
>
>
>
> Hi,
>
> I've built openjdk7 on NetBSD 5.0_STABLE amd64 with modular xorg from xsrc.
>
> I'm running pkgsrc/www/paros with it, but the fonts look really ugly.
> Please
> have a look at the attached screenshots; one is with wip/jdk16 (or
> wip/jdk15)
> and the other with lang/openjdk7.
>
> I suspect a fontconfig issue (base vs pkgsrc fontconfig configuration?) but
> `ldd` shows both java binaries are linked only to libc and libpthread?
>
>
> Geert
>
>
> --
> Geert Hendrickx -=- ghen@... -=- PGP: 0xC4BB9E9F
> This e-mail was composed using 100% recycled spam messages!
>

--
Sent from my mobile device

Re: openjdk7 in pkgsrc

2009-10-20T13:57:52Z

On Wed, Oct 14, 2009 at 03:26:31PM +0200, Tobias Nygren wrote:
> Hi,
>
> I've imported an experimental source-based JDK package to
> pkgsrc/lang/openjdk7. Feel free to test and to contribute fixes.
> It should build on NetBSD>=5 i386 and amd64, native and modular
> X.org. Support for Linux and DragonFlyBSD will be added soon.

Hi,

I've built openjdk7 on NetBSD 5.0_STABLE amd64 with modular xorg from xsrc.

I'm running pkgsrc/www/paros with it, but the fonts look really ugly. Please
have a look at the attached screenshots; one is with wip/jdk16 (or wip/jdk15)
and the other with lang/openjdk7.

I suspect a fontconfig issue (base vs pkgsrc fontconfig configuration?) but
`ldd` shows both java binaries are linked only to libc and libpthread?

Geert

--
Geert Hendrickx -=- ghen@... -=- PGP: 0xC4BB9E9F
This e-mail was composed using 100% recycled spam messages!

paros_jdk6.png (9K) Download Attachment
paros_openjdk7.png (10K) Download Attachment

Re: openjdk7 in pkgsrc

2009-10-14T08:38:30Z

On Wed, Oct 14, 2009 at 03:26:31PM +0200, Tobias Nygren wrote:
> Hi,
>
> I've imported an experimental source-based JDK package to
> pkgsrc/lang/openjdk7. Feel free to test and to contribute fixes.
> It should build on NetBSD>=5 i386 and amd64, native and modular X.org.
> Support for Linux and DragonFlyBSD will be added soon.

lang/openjdk7 built correctly but www/openjdk7-icedtea-plugin has problems.
Firstly configure wants wget so it should be added as a build dependency.
But then it fails with:

checking for XP... no
configure: error: Could not find Xp - Try installing libXp-devel.
*** Error code 1

Although the buildlink wrappers are there...

Geert

--
Geert Hendrickx -=- ghen@... -=- PGP: 0xC4BB9E9F
This e-mail was composed using 100% recycled spam messages!

openjdk7 in pkgsrc

2009-10-14T06:26:31Z

Hi,

I've imported an experimental source-based JDK package to
pkgsrc/lang/openjdk7. Feel free to test and to contribute fixes.
It should build on NetBSD>=5 i386 and amd64, native and modular X.org.
Support for Linux and DragonFlyBSD will be added soon.

Have fun,
-Tobias

Re: openjdk 1.7.0 attempt

2009-10-13T16:21:41Z

David Brownlee wrote:

>2009/10/13 Robert Swindells <rjs@...>
>> Patrick Welche wrote:
>> >I just had a go with jdk1.7.0-200905020i386-netBSD-5.0.tar.bz2 on a
>> >5.99.12/i386 box, and my first swing programme:
>>
>> [snip]
>>
>> >% java hellow
>> >Exception in thread "AWT-EventQueue-0"
>> >java.lang.ArrayIndexOutOfBoundsException: 0
>> > at sun.awt.X11.XIconInfo.<init>(XIconInfo.java:74)
>> > at
>> sun.awt.X11.XWindowPeer.getDefaultIconInfo(XWindowPeer.java:406)
>> > at sun.awt.X11.XWindowPeer.updateIconImages(XWindowPeer.java:308)
>>
>> [snip]
>>
>> I get the same error with any graphical application too.
>>
>> I think this may be a build problem with the openjdk7-bin package.
>>
>> The exception is generated because the arrays of icon data in rt.jar
>> are zero length. The class files containing the icon data have been
>> automatically generated from .png files using a java app (in
>> ToBin.java) which renders them then extracts the raw data.
>>
>> I haven't found a way to get ToBin to fail yet, it still works if
>> DISPLAY isn't set. Which JDK was used to build the binary package ?
>>
>> Robert Swindells
>
>Have you tried the wip/openjdk package? I've found I'm able to run
>graphical java apps without issues (much kudos to those who worked on
>it).

I haven't tried it yet but will do, I have had a look at it. My guess
is that openjdk7-bin was built using a JDK that didn't have png
support, wip/openjdk won't have this problem as it rebuilds itself
after the initial cross-compile has finished.

I just rebuilt the icon files using openjdk7-bin and patched rt.jar,
the graphical demos work fine for me now.

I have put a tarball of the fixed class files onto ftp.n.o at:

ftp://ftp.netbsd.org/pub/NetBSD/misc/rjs/rt-patch.tar.bz2

To use it, untar it somewhere then run:

# jar uvf /usr/pkg/java/openjdk-bin/jre/lib/rt.jar sun/awt/X11/*.class

Robert Swindells

Re: openjdk 1.7.0 attempt

2009-10-13T07:20:30Z

Patrick Welche wrote:
>I just had a go with jdk1.7.0-200905020i386-netBSD-5.0.tar.bz2 on a
>5.99.12/i386 box, and my first swing programme:

[snip]

>% java hellow
>Exception in thread "AWT-EventQueue-0"
>java.lang.ArrayIndexOutOfBoundsException: 0
> at sun.awt.X11.XIconInfo.<init>(XIconInfo.java:74)
> at sun.awt.X11.XWindowPeer.getDefaultIconInfo(XWindowPeer.java:406)
> at sun.awt.X11.XWindowPeer.updateIconImages(XWindowPeer.java:308)

[snip]

I get the same error with any graphical application too.

I think this may be a build problem with the openjdk7-bin package.

The exception is generated because the arrays of icon data in rt.jar
are zero length. The class files containing the icon data have been
automatically generated from .png files using a java app (in
ToBin.java) which renders them then extracts the raw data.

I haven't found a way to get ToBin to fail yet, it still works if
DISPLAY isn't set. Which JDK was used to build the binary package ?

Robert Swindells

Re: openjdk on netbsd

2009-10-01T12:00:22Z

Cool. I'll definitely have a look at the pkgsrc-wip work when I get
back to this.

cheers!
b

On Thu, Oct 1, 2009 at 4:09 AM, Tobias Nygren <tnn@...> wrote:

> On Wed, 30 Sep 2009 18:29:13 -0400
> Brent Verner <dbv@...> wrote:
>
>> Sometime over the next few weeks, I'll try to make time to create a
>> pkgsrc port for this. The changes are largely based on the work of
>> the freebsd port, so if you want to thank someone, they deserve all
>> of the kudos. Let me know how this works for you if you get a chance
>> to try it out.
>
> To avoid duplication of effort, you might want to have a look at
> openjdk from pkgsrc-wip which was recently resurrected.
> I plan to import it to pkgsrc after 2009Q3 is cut.
> An openjdk6 package could probably share much code.
>

Re: openjdk on netbsd

2009-10-01T01:09:26Z

On Wed, 30 Sep 2009 18:29:13 -0400
Brent Verner <dbv@...> wrote:

> Sometime over the next few weeks, I'll try to make time to create a
> pkgsrc port for this. The changes are largely based on the work of
> the freebsd port, so if you want to thank someone, they deserve all
> of the kudos. Let me know how this works for you if you get a chance
> to try it out.

To avoid duplication of effort, you might want to have a look at
openjdk from pkgsrc-wip which was recently resurrected.
I plan to import it to pkgsrc after 2009Q3 is cut.
An openjdk6 package could probably share much code.

openjdk on netbsd

2009-09-30T15:29:13Z

Hi,

I ran into an issue trying to run my app on openjdk7/netbsd and in
the process of trying to debug my problem, I ended up building openjdk6.

The problem was due to a buglet in the configuration for the
SecureRandom class that caused it to read from /dev/random (and hang).
Apparently, the "file:" url syntax has been changed and the correct
system property in the ${JAVA_HOME}/jre/lib/security/java.security
file in the openjdk7 package should be:

securerandom.source=file:///dev/urandom

I spent the time to get openjdk6 to build because I needed the
newer versions of jaxws/jaxb (for a spring/apache-cxf app). If anyone
is interested in trying a native openjdk6, you can grab it from here:

http://xen-1.stable.netavail.net/~brent/openjdk6

See the _README.txt.

Sometime over the next few weeks, I'll try to make time to create a
pkgsrc port for this. The changes are largely based on the work of
the freebsd port, so if you want to thank someone, they deserve all
of the kudos. Let me know how this works for you if you get a chance
to try it out.

enjoy!
Brent

Be advised accordingly!!

2009-07-28T07:01:28Z

REFERENCE: SNS/NL/0671341/09

BE ADVISED ACCORDINGLY

Be informed that my previous mail was not responded to and found it necessary to write you again.

It may interest you to know a comprehensive search revealed your last name to be same with a customer of the SNS Bank (now deceased) whom my bank’s efforts to locate his relatives have been unsuccessful. The benefit from this dormant account worth millions in dollars is awaiting payment to a potential heir/beneficiary.

Putting into consideration this, my job as head of compensation and benefits and the legal requirement of claims like this, your last name can pass for a heir to this huge amount. You need not worry about the legal requirement as you shall be closely guided and directed on this.

Kindly respond with your name as it is in your driver's license or international passport and your direct telephone number to signify interest.

Be advised to keep this very important notice to yourself until advised otherwise.This will be done in your best interest.

Yours Faithfully,
Chris Veenstra

Re: sun-jdk15 do not work on netbsd4-amd64

2009-07-20T17:17:02Z

On 21/07/2009 12:13 AM, Milos Negovanovic wrote:
> On Mon, Jul 20, 2009 at 09:43:14AM -0400, matthew sporleder wrote:
>> Can you use a newer JVM or a newer NetBSD? There were some builds
>> done of openjdk 1.7 for netbsd 5. You can find them in the
>> netbsd-java mailing list archives and in pkgsrc-wip.
>
> I am not aware of a single jdk package which works under netbsd-5/amd64,
> did I miss something?

I compiled openjdk under current/amd64 a while back with no issue. There
is no working 'sun' version that I'm aware of. Most dump core/segfault
from memory.

Sarton

Re: sun-jdk15 do not work on netbsd4-amd64

2009-07-20T13:40:39Z

On Mon, Jul 20, 2009 at 10:13 AM, Milos
Negovanovic<milos.negovanovic@...> wrote:
> On Mon, Jul 20, 2009 at 09:43:14AM -0400, matthew sporleder wrote:
>> Can you use a newer JVM or a newer NetBSD? There were some builds
>> done of openjdk 1.7 for netbsd 5. You can find them in the
>> netbsd-java mailing list archives and in pkgsrc-wip.
>
> I am not aware of a single jdk package which works under netbsd-5/amd64,
> did I miss something?
>

Have you tried one of these:
ftp://ftp.netbsd.org/pub/NetBSD/misc/java/openjdk/

Re: sun-jdk15 do not work on netbsd4-amd64

2009-07-20T07:13:01Z

On Mon, Jul 20, 2009 at 09:43:14AM -0400, matthew sporleder wrote:
> Can you use a newer JVM or a newer NetBSD? There were some builds
> done of openjdk 1.7 for netbsd 5. You can find them in the
> netbsd-java mailing list archives and in pkgsrc-wip.

I am not aware of a single jdk package which works under netbsd-5/amd64,
did I miss something?

Regards
--
Milos Negovanovic
milos.negovanovic@...

Re: sun-jdk15 do not work on netbsd4-amd64

2009-07-20T06:43:14Z

On Mon, Jul 20, 2009 at 7:35 AM, Water NB<netbsd78@...> wrote:

> I have a netbsd4-amd64 PC, when I run
>
> # /usr/pkg/java/sun-1.5/bin/java -h
> Usage: java [-options] class [args...]
> ...
>
> (Program output help message correctly.)
>
> # /usr/pkg/java/sun-1.5/bin/java -version
>
> (Program sleep here without any message and do not exit.)
>
>
> # /usr/pkg/java/sun-1.5/bin/java -jar xxx.jar
>
> (Program sleep here without any message and do not exit.)
>
>
> Anyone can tell me why or who can run sun-jdk15 correctly on
> netbsd4-amd6?
>

Can you use a newer JVM or a newer NetBSD? There were some builds
done of openjdk 1.7 for netbsd 5. You can find them in the
netbsd-java mailing list archives and in pkgsrc-wip.

sun-jdk15 do not work on netbsd4-amd64

2009-07-20T04:35:10Z

I have a netbsd4-amd64 PC, when I run

# /usr/pkg/java/sun-1.5/bin/java -h
Usage: java [-options] class [args...]
...

(Program output help message correctly.)

# /usr/pkg/java/sun-1.5/bin/java -version

(Program sleep here without any message and do not exit.)

# /usr/pkg/java/sun-1.5/bin/java -jar xxx.jar

(Program sleep here without any message and do not exit.)

Anyone can tell me why or who can run sun-jdk15 correctly on
netbsd4-amd6?

Thanks.

openjdk 1.7.0 attempt

2009-05-31T07:49:05Z

I just had a go with jdk1.7.0-200905020i386-netBSD-5.0.tar.bz2 on a
5.99.12/i386 box, and my first swing programme:

import javax.swing.*;

public class hellow {
private static void gui() {
JFrame frame = new JFrame("title of frame");
frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);

JLabel label = new JLabel("Hello World!");
frame.getContentPane().add(label);

frame.pack();
frame.setVisible(true);
}

public static void main(String[] args) {
javax.swing.SwingUtilities.invokeLater(
new Runnable() {
public void run() {
gui();
}
}
);
}
}

(javac hellow.class creates hellow.class and hello$1.class, then
setenv LD_LIBRARY_PATH /lib:/usr/lib:/usr/X11R7/lib
and:)

% java hellow
Exception in thread "AWT-EventQueue-0" java.lang.ArrayIndexOutOfBoundsException: 0
at sun.awt.X11.XIconInfo.<init>(XIconInfo.java:74)
at sun.awt.X11.XWindowPeer.getDefaultIconInfo(XWindowPeer.java:406)
at sun.awt.X11.XWindowPeer.updateIconImages(XWindowPeer.java:308)
at sun.awt.X11.XWindowPeer.postInit(XWindowPeer.java:262)
at sun.awt.X11.XDecoratedPeer.postInit(XDecoratedPeer.java:91)
at sun.awt.X11.XFramePeer.postInit(XFramePeer.java:86)
at sun.awt.X11.XBaseWindow.init(XBaseWindow.java:185)
at sun.awt.X11.XBaseWindow.<init>(XBaseWindow.java:261)
at sun.awt.X11.XWindow.<init>(XWindow.java:127)
at sun.awt.X11.XComponentPeer.<init>(XComponentPeer.java:118)
at sun.awt.X11.XCanvasPeer.<init>(XCanvasPeer.java:43)
at sun.awt.X11.XPanelPeer.<init>(XPanelPeer.java:46)
at sun.awt.X11.XWindowPeer.<init>(XWindowPeer.java:109)
at sun.awt.X11.XDecoratedPeer.<init>(XDecoratedPeer.java:57)
at sun.awt.X11.XFramePeer.<init>(XFramePeer.java:54)
at sun.awt.X11.XToolkit.createFrame(XToolkit.java:389)
at java.awt.Frame.addNotify(Frame.java:476)
at java.awt.Window.pack(Window.java:710)
at hellow.gui(hellow.java:11)
at hellow.access$000(hellow.java:3)
at hellow$1.run(hellow.java:19)
at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:235)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:603)
at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:286)
at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:201)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:191)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:186)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:178)
at java.awt.EventDispatchThread.run(EventDispatchThread.java:139)

So what can I try next? (Any ideas on using midp?)

Cheers,

Patrick

openjdk-7 with NetBSD5

2009-05-07T06:43:23Z

Hi,

I've just installed the new OpenJDK7 binaries from pkgsrc on my freshly
configured NetBSD5.0/i386 system, but I cannot get it to work.

Unfortunately there is no RPATH set in the Java libraries, so I
tried it with "export LD_LIBRARY_PATH=/usr/X11R7/lib". But then I
get a core dump with my small application:

#
# A fatal error has been detected by the Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0x08053b60, pid=3009, tid=3131047936
#
# JRE version: 7.0
# Java VM: OpenJDK Server VM (14.0-b10 mixed mode bsd-x86 )
# Problematic frame:
# C [java+0xbb60] inflate_fast+0x18
[...]

The stack frame from the crash log:
---8<---
Stack: [0xbaa02000,0xbac00000], sp=0xbabfdc1c, free space=2031k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C [java+0xbb60] inflate_fast+0x18
C [libz.so.1+0x5d9b] inflate+0x194f
C [libfreetype.so.6+0x35d46] FT_Stream_OpenLZW+0x5a2
C [libfreetype.so.6+0x35e99] FT_Stream_OpenLZW+0x6f5
C [libfreetype.so.6+0x4c579] FT_Stream_EnterFrame+0x5d
C [libfreetype.so.6+0x4d6cd] FT_Stream_ReadFields+0x95
C [libfreetype.so.6+0x33a96] ps_hints_apply+0x8e8e
C [libfreetype.so.6+0x34fa3] ps_hints_apply+0xa39b
C [libfreetype.so.6+0x4e7d4] FT_New_Size+0x214
C [libfreetype.so.6+0x500d1] FT_Open_Face+0xc5
C [libfreetype.so.6+0x50e4a] FT_New_Face+0x36
C [libfontconfig.so.1+0x1202a] FcFreeTypeQuery+0x46
C [libfontconfig.so.1+0x12667] FcFileIsDir+0xbf
C [libfontconfig.so.1+0x12a18] FcFileIsDir+0x470
C [libfontconfig.so.1+0x12a9c] FcDirCacheRead+0x20
C [libfontconfig.so.1+0x169cf] FcConfigGetConfigDirs+0x1bf
C [libfontconfig.so.1+0x16c0d] FcConfigBuildFonts+0x3d
C [libfontconfig.so.1+0xf098] FcInitLoadConfigAndFonts+0x20
C [libfontconfig.so.1+0xf169] FcInit+0x2d
C [libfontconfig.so.1+0x15f90] FcConfigGetCurrent+0x2c
C [libfontconfig.so.1+0x167e2] FcConfigGetCacheDirs+0x22
C [libmawt.so+0x22991] Java_sun_font_FontManager_getFontConfig+0x4b9
j
sun.font.FontManager.getFontConfig(Ljava/lang/String;Lsun/font/FontManager$FontConfigInfo;[Lsun/font/FontManager$FcCompFont;Z)V+0
j sun.font.FontManager.initFontConfigFonts(Z)V+165
j sun.font.FontManager.loadFontConfig()[Lsun/font/FontManager$FcCompFont;+1
j sun.font.FcFontConfiguration.init()Z+21
j sun.font.FcFontConfiguration.<init>(Lsun/java2d/SunGraphicsEnvironment;)V+16
j
sun.awt.X11GraphicsEnvironment.createFontConfiguration()Lsun/awt/FontConfiguration;+53
j sun.java2d.SunGraphicsEnvironment$2.run()Ljava/lang/Object;+496
v ~StubRoutines::call_stub
V [libjvm.so+0x38548c]
V [libjvm.so+0x5237d9]
V [libjvm.so+0x38441f]
V [libjvm.so+0x3ecd05]
C [libjava.so+0xb1cd]
Java_java_security_AccessController_doPrivileged__Ljava_security_PrivilegedAction_2+0x25
j
java.security.AccessController.doPrivileged(Ljava/security/PrivilegedAction;)Ljava/lang/Object;+0
j sun.java2d.SunGraphicsEnvironment.<init>()V+44
j sun.awt.X11GraphicsEnvironment.<init>()V+1
v ~StubRoutines::call_stub
V [libjvm.so+0x38548c]
V [libjvm.so+0x5237d9]
V [libjvm.so+0x38441f]
V [libjvm.so+0x581176]
V [libjvm.so+0x581a33]
V [libjvm.so+0x3ef581]
C [libjava.so+0x13689]
Java_sun_reflect_NativeConstructorAccessorImpl_newInstance0+0x21
j
sun.reflect.NativeConstructorAccessorImpl.newInstance0(Ljava/lang/reflect/Constructor;[Ljava/lang/Object;)Ljava/lang/Object;+0
j
sun.reflect.NativeConstructorAccessorImpl.newInstance([Ljava/lang/Object;)Ljava/lang/Object;+72
j
sun.reflect.DelegatingConstructorAccessorImpl.newInstance([Ljava/lang/Object;)Ljava/lang/Object;+5
j
java.lang.reflect.Constructor.newInstance([Ljava/lang/Object;)Ljava/lang/Object;+92
j java.lang.Class.newInstance0()Ljava/lang/Object;+118
j java.lang.Class.newInstance()Ljava/lang/Object;+15
j
java.awt.GraphicsEnvironment.getLocalGraphicsEnvironment()Ljava/awt/GraphicsEnvironment;+27
j sun.awt.X11.XToolkit.<clinit>()V+107
v ~StubRoutines::call_stub
V [libjvm.so+0x38548c]
V [libjvm.so+0x5237d9]
V [libjvm.so+0x38441f]
V [libjvm.so+0x363e3e]
V [libjvm.so+0x364369]
V [libjvm.so+0x3dbf18]
V [libjvm.so+0x3dc5bf]
V [libjvm.so+0x3e13c5]
C [libjava.so+0xb812] Java_java_lang_Class_forName0+0xd6
j
java.lang.Class.forName0(Ljava/lang/String;ZLjava/lang/ClassLoader;)Ljava/lang/Class;+0
j java.lang.Class.forName(Ljava/lang/String;)Ljava/lang/Class;+5
j java.awt.Toolkit$2.run()Ljava/lang/Object;+13
v ~StubRoutines::call_stub
V [libjvm.so+0x38548c]
V [libjvm.so+0x5237d9]
V [libjvm.so+0x38441f]
V [libjvm.so+0x3ecd05]
C [libjava.so+0xb1cd]
Java_java_security_AccessController_doPrivileged__Ljava_security_PrivilegedAction_2+0x25
j
java.security.AccessController.doPrivileged(Ljava/security/PrivilegedAction;)Ljava/lang/Object;+0
j java.awt.Toolkit.getDefaultToolkit()Ljava/awt/Toolkit;+16
j javax.swing.UIManager.getSystemLookAndFeelClassName()Ljava/lang/String;+58
j JavaGraphicApp.main([Ljava/lang/String;)V+0
v ~StubRoutines::call_stub
V [libjvm.so+0x38548c]
V [libjvm.so+0x5237d9]
V [libjvm.so+0x38441f]
V [libjvm.so+0x38e1d5]
V [libjvm.so+0x3a6480]
C [java+0x3c83] JavaMain+0xa87
C [libpthread.so.0+0x99df] pthread_create+0x5bb

---8<---

Anything I can do about it?
I'm not a Java programmer, but I need it for an application.

--
Frank Wille

Default JVM for NetBSD-5-i386 is now openjdk7-bin

2009-04-29T02:11:01Z

Hi David,

Is this possible to build openoffice 3 with openjdk7 ?

Thanks in advance,
Nicolas.

Default JVM for NetBSD-5-i386 is now openjdk7-bin

2009-04-10T02:31:02Z

I've changed the default pkgsrc JVM for NetBSD/i386 5.x to
openjdk7-bin

The previous default - the linux sun-jre6 - would randomly crash
under load for at least tomcat and jboss

Other architectures, OSs & versions are unchanged.

Re: wip/jdk15 and NetBSD 5

2009-03-10T04:37:49Z

On Sat, 7 Mar 2009, Geert Hendrickx wrote:

> On Fri, Mar 06, 2009 at 08:46:43PM +0000, David Brownlee wrote:
>> On Fri, 6 Mar 2009, David Brownlee wrote:
>>
>>> I have some cleanups to wip/jdk15 that I'm just finishing
>>> testing. If you want to hold off just a little with PLIST
>>> fixes that would be ideal...
>>
>> OK, I'm clear of wip/jdk15 :)
>>
>> How is your PLIST munging going? :)
>
>
> Most of the problems go away if I enable the jdk15-plugin option (the TODO
> list mentions the installation without plugin is still broken). The files

PLIST without jdk15-plugin should be fixed

> in PLIST with ${MACHINE_ARCH} are wrong because ${MACHINE_ARCH} expands to
> x86_64 while the files are installed under amd64. After manually replacing

That should also be fixed.

> that, the only four missing files are:
>
> ERROR: ************************************************************
> ERROR: The following files are in the PLIST but not in /usr/pkg:
> ERROR: /usr/pkg/java/jdk-1.5.0/bin/java-rmi.cgi
> ERROR: /usr/pkg/java/jdk-1.5.0/jre/lib/amd64/client/Xusage.txt
> ERROR: /usr/pkg/java/jdk-1.5.0/jre/lib/amd64/client/libjsig.so
> ERROR: /usr/pkg/java/jdk-1.5.0/jre/lib/amd64/client/libjvm.so
> *** Error code 1

That is... very odd. That the last three imply the client VM is
not being built for amd64. Does 'java -client' work?. As for
java-rmi.cgi, I have no idea why it would be omitted...

> Now, when starting up firefox3 or seamonkey with the plugin and trying to
> use it, it prints on the console:
>
> Cannot open "/home/lib/amd64/libjavaplugin_nscp.so"
>
> After symlinking /usr/pkg/java/jdk-1.5.0/jre/lib to /home/lib and bumping
> the datasize limit, the java plugin starts, but only displays a red cross
> and the java console shows a bunch of classloader errors. But it runs!
> (the java console itself is a Java program)

Interesting... on i386 NetBSD 5 symlinking
/usr/pkg/java/jdk-1.5.0/jre/plugin/i386/ns7/libjavaplugin_oji.so
into firefox's plugin directory is enough to get java working
in firefox3 - tested by going to
http://www.bubblemark.com/java.html (57 fps on my T60p)

I wonder why the amd64 build is so different...
--
David/absolute -- www.NetBSD.org: No hype required --

Re: wip/jdk15 and NetBSD 5

2009-03-07T00:54:26Z

On Fri, Mar 06, 2009 at 08:46:43PM +0000, David Brownlee wrote:
> On Fri, 6 Mar 2009, David Brownlee wrote:
>
>> I have some cleanups to wip/jdk15 that I'm just finishing
>> testing. If you want to hold off just a little with PLIST
>> fixes that would be ideal...
>
> OK, I'm clear of wip/jdk15 :)
>
> How is your PLIST munging going? :)

Most of the problems go away if I enable the jdk15-plugin option (the TODO
list mentions the installation without plugin is still broken). The files
in PLIST with ${MACHINE_ARCH} are wrong because ${MACHINE_ARCH} expands to
x86_64 while the files are installed under amd64. After manually replacing
that, the only four missing files are:

ERROR: ************************************************************
ERROR: The following files are in the PLIST but not in /usr/pkg:
ERROR: /usr/pkg/java/jdk-1.5.0/bin/java-rmi.cgi
ERROR: /usr/pkg/java/jdk-1.5.0/jre/lib/amd64/client/Xusage.txt
ERROR: /usr/pkg/java/jdk-1.5.0/jre/lib/amd64/client/libjsig.so
ERROR: /usr/pkg/java/jdk-1.5.0/jre/lib/amd64/client/libjvm.so
*** Error code 1

Now, when starting up firefox3 or seamonkey with the plugin and trying to
use it, it prints on the console:

Cannot open "/home/lib/amd64/libjavaplugin_nscp.so"

After symlinking /usr/pkg/java/jdk-1.5.0/jre/lib to /home/lib and bumping
the datasize limit, the java plugin starts, but only displays a red cross
and the java console shows a bunch of classloader errors. But it runs!
(the java console itself is a Java program)

Geert

--
Geert Hendrickx -=- ghen@... -=- PGP: 0xC4BB9E9F
This e-mail was composed using 100% recycled spam messages!

Re: wip/jdk15 and NetBSD 5

2009-03-06T12:46:43Z

On Fri, 6 Mar 2009, David Brownlee wrote:

> I have some cleanups to wip/jdk15 that I'm just finishing
> testing. If you want to hold off just a little with PLIST
> fixes that would be ideal...

OK, I'm clear of wip/jdk15 :)

How is your PLIST munging going? :)

--
David/absolute -- www.NetBSD.org: No hype required --

Re: wip/jdk15 and NetBSD 5

2009-03-06T09:45:08Z

On Fri, 6 Mar 2009, Geert Hendrickx wrote:

> On Fri, Mar 06, 2009 at 03:57:14PM +0000, David Brownlee wrote:
>> Hmm... I assume adding -lgcc_s to LINK_LIB in vm.make doesn't help? (I
>> don't have any amd64 boxes to test)
>
>
> Wrong assumption, it does. :-)
>
> I had to substitute s/bsd-i586/bsd-amd64/ in the Makefile to get it
> installed, and there are still some installation and PLIST troubles,
> Jut at least the build worked!

Excellent! :)

I have some cleanups to wip/jdk15 that I'm just finishing
testing. If you want to hold off just a little with PLIST
fixes that would be ideal...

Does anyone know if there are there still issues distributing
patches to jdk15 that prevent importing it into main pkgsrc?

--
David/absolute -- www.NetBSD.org: No hype required --

Re: wip/jdk15 and NetBSD 5

2009-03-06T09:35:56Z

On Fri, Mar 06, 2009 at 03:57:14PM +0000, David Brownlee wrote:
> Hmm... I assume adding -lgcc_s to LINK_LIB in vm.make doesn't help? (I
> don't have any amd64 boxes to test)

Wrong assumption, it does. :-)

I had to substitute s/bsd-i586/bsd-amd64/ in the Makefile to get it
installed, and there are still some installation and PLIST troubles,
Jut at least the build worked!

Geert

--
Geert Hendrickx -=- ghen@... -=- PGP: 0xC4BB9E9F
This e-mail was composed using 100% recycled spam messages!

Importing wip/jdk

2009-03-06T09:00:44Z

Are there still issues with distributing patches fpor jdk15?
If not, could it be imported into pkgsrc. If there are, would it be
acceptable for someone to put up the patches as a single patchfile
somewhere and import a package which downloads them similar
to jdk15.patches?

Re: wip/jdk15 and NetBSD 5

2009-03-06T07:57:14Z

On Fri, 6 Mar 2009, Geert Hendrickx wrote:

> On Fri, Mar 06, 2009 at 12:58:03PM +0000, David Brownlee wrote:
>> wip/jdk15 should now build and run on NetBSD 5 - for anyone
>> interested in a somewhat old but functional JVM :)
>
>
> Trying to build wip/jdk15 on NetBSD 5.0 amd64, I get the following error in
> hotspot/src/os_cpu/bsd_amd64/vm/os_bsd_amd64.cpp on line 610:
>
> 'block_on_serialize_page_trap' is not a member of 'os'
>
> After simply commenting out that line, the build continues for a while and
> then breaks at:
>
> /scratch/pkgsrc/work/wip/jdk15/work/control/build/bsd-amd64/bin/java -classpath ../../../tools/CompileProperties CompileProperties ../../../../src/share/classes/com/sun/tools/javac/resources/compiler.properties /scratch/pkgsrc/work/wip/jdk15/work/control/build/bsd-amd64/gensrc/com/sun/tools/javac/resources/compiler.java
> dl failure on line 730Error: failed /scratch/pkgsrc/work/wip/jdk15/work/control/build/bsd-amd64/lib/amd64/server/libjvm.so, because /usr/lib/libstdc++.so.6: Undefined PLT symbol "_Unwind_GetIP" (symnum = 158)
> gmake[6]: *** [/scratch/pkgsrc/work/wip/jdk15/work/control/build/bsd-amd64/gensrc/com/sun/tools/javac/resources/compiler.java] Error 6

Hmm... I assume adding -lgcc_s to LINK_LIB in vm.make doesn't
help? (I don't have any amd64 boxes to test)

--
David/absolute -- www.NetBSD.org: No hype required --