FC6 gcj notes

[Anthony Green]

A few random FC6 gcj comments...

I'm not sure if this has been mentioned on the list at all, but since
FC6 will be shipping with GCC 4.1.x, a decision has been made to
backport all the great GNU Classpath/libgcj work from GCC HEAD into the
FC6 4.1.x branch. Among other things, this means we'll also get
gcjwebplugin. 

The whitelist dialog box in gcjwebplugin is pretty intimidating.  I was
wondering if we could add a button to it that would pop up a Fedora wiki
page in a browser explaining the situation a little better to newbies.
I'd be willing to write the page if somebody could add the button.


FE now contains all of the dependencies for the MIDI synthesizer
providers I wrote (dssi, jack-audio-connection-kit, etc).  I'm not
willing to bet we can pull these into Core.  Should I extract those
providers from GNU Classpath and make an FE package out of them?


Having Eclipse 3.2 in FC6 is awesome.  I am able to remove a number of
SWT patches from azureus and rssowl now that we have SWT 3.2.
However...
I can't optimize Azureus because of this:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19505
RSSOwl won't run because of this:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27271

Are there any other pet bugs that need to be fixed before FC6?


Karsten hasn't been asking me about FOP for a long time.  I wonder if
that means the Fedora docs guys have moved on to a different PDF
solution.  I suspect that FOP will run with the FC6 gcj.  Any reason to
believe otherwise?

AG

[Andrew Haley]

Anthony Green writes:
 
>  The whitelist dialog box in gcjwebplugin is pretty intimidating.
Good!  The intention (surely?) is to make sure the chance of someone
not understanding the situation is zero.

>  I was wondering if we could add a button to it that would pop up a
>  Fedora wiki page in a browser explaining the situation a little
>  better to newbies.  I'd be willing to write the page if somebody
>  could add the button.
>  
>  
>  FE now contains all of the dependencies for the MIDI synthesizer
>  providers I wrote (dssi, jack-audio-connection-kit, etc).  I'm not
>  willing to bet we can pull these into Core.  Should I extract those
>  providers from GNU Classpath and make an FE package out of them?
>  
>  
>  Having Eclipse 3.2 in FC6 is awesome.  I am able to remove a number of
>  SWT patches from azureus and rssowl now that we have SWT 3.2.
>  However...
>  I can't optimize Azureus because of this:
>  http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19505 
Mmm.  Jeff Law suggested
<http://gcc.gnu.org/ml/gcc-patches/2005-10/msg00124.html> a way to
rewrite that patch which might be acceptable.  I may be able to
investigate this week.

Andrew.

[Mark Wielaard]

Hi,

On Sun, 2006-07-09 at 10:06 -0700, Anthony Green wrote:
>  I'm not sure if this has been mentioned on the list at all, but
> since
>  FC6 will be shipping with GCC 4.1.x, a decision has been made to
>  backport all the great GNU Classpath/libgcj work from GCC HEAD into the
>  FC6 4.1.x branch. Among other things, this means we'll also get
>  gcjwebplugin.  
Great! This will be a huge boost in the number of applications that can
be supported on the free stack in FC6 out of the box.

But note that the GNU Classpath on GCC HEAD is some bastard "gui only"
port of an old GNU Classpath CVS version from about a month ago. It has
some really embarrassing bugs in it. We did a lot of testing and fixing
of the graphics layer since then (and at least one really nasty bug was
fixed only this weekend). So you really don't want to ship with what is
in GCC HEAD now. At the minimum a new sync with Classpath CVS should be
done for the graphics layers. We will try to make a new GNU Classpath
snapshot soon (this weekend/next week, but no promises) that has gone
through all the QA procedures. A lot of application smoke testing has
been done in the last week, but at least a full comparision for
regressions against the full Mauve testsuite should be done before we
can be confident about creating a new release.

Cheers,

Mark

[Thomas Fitzsimmons]

Mark Wielaard wrote:
>  Hi,
>  
>  On Sun, 2006-07-09 at 10:06 -0700, Anthony Green wrote:
> > I'm not sure if this has been mentioned on the list at all, but since
> > FC6 will be shipping with GCC 4.1.x, a decision has been made to
> > backport all the great GNU Classpath/libgcj work from GCC HEAD into the
> > FC6 4.1.x branch. Among other things, this means we'll also get
> > gcjwebplugin. 
>  
>  Great! This will be a huge boost in the number of applications that can
>  be supported on the free stack in FC6 out of the box.
>  
>  But note that the GNU Classpath on GCC HEAD is some bastard "gui only"
>  port of an old GNU Classpath CVS version from about a month ago. It has
>  some really embarrassing bugs in it. We did a lot of testing and fixing
>  of the graphics layer since then (and at least one really nasty bug was
>  fixed only this weekend). So you really don't want to ship with what is
>  in GCC HEAD now. At the minimum a new sync with Classpath CVS should be
>  done for the graphics layers. We will try to make a new GNU Classpath
>  snapshot soon (this weekend/next week, but no promises) that has gone
>  through all the QA procedures. A lot of application smoke testing has
>  been done in the last week, but at least a full comparision for
>  regressions against the full Mauve testsuite should be done before we
>  can be confident about creating a new release. 
Yes, if the schedules work out I'd like to see the new GNU Classpath snapshot 
imported to GCJ mainline and the Red Hat 4.1 branch (Rawhide), between FC6test2 
and FC6test3.  That said, everything is stalled on the libgcj-bc.so work right 
now.  If that isn't done in time we'll be stuck with GCJ 4.1 stock in FC6.

Tom

[Anthony Green]

On Tue, 2006-07-11 at 09:53 -0400, Thomas Fitzsimmons wrote:
>   That said, everything is stalled on the libgcj-bc.so work right 
>  now.  If that isn't done in time we'll be stuck with GCJ 4.1 stock in
>  FC6.  
Ouch.  Is libgcj-bc.so is supposed to be library that
-findirect-dispatch binaries link against?  What is the advantage of
introducing this?

AG

[Thomas Fitzsimmons]

Anthony Green wrote:
>  On Tue, 2006-07-11 at 09:53 -0400, Thomas Fitzsimmons wrote:
> >  That said, everything is stalled on the libgcj-bc.so work right 
> > now.  If that isn't done in time we'll be stuck with GCJ 4.1 stock in
> > FC6. 
>  
>  Ouch.  Is libgcj-bc.so is supposed to be library that
>  -findirect-dispatch binaries link against?  What is the advantage of
>  introducing this? 
libgcj-bc.so's SONAME (libgcj-bc.so.1) stays constant, meaning that BC libraries 
do not need to be relinked when libgcj.so's version changes.

Tom

[Tom Tromey]

> >>>> "Tom" == Thomas Fitzsimmons
> <fitzsim(a)redhat.com&gt; writes: 
Tom> Yes, if the schedules work out I'd like to see the new GNU Classpath
Tom> snapshot imported to GCJ mainline and the Red Hat 4.1 branch
Tom> (Rawhide), between FC6test2 and FC6test3.

Piling on, I'd like us to ship the 'ecj' branch of gcj instead.
This is a major upgrade including generics.

It's not clear whether we can do this in a reasonable timeframe though.
And I'm sure some would argue that we've already passed the point of
reasonableness.

Tom

[David Walluck]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Tom Tromey wrote:
>  Piling on, I'd like us to ship the 'ecj' branch of gcj
> instead.
>  This is a major upgrade including generics. 
Does the ecj branch have any runtime support for generics, or is it just
compile-time support?

>  It's not clear whether we can do this in a reasonable timeframe
> though.
>  And I'm sure some would argue that we've already passed the point of
>  reasonableness. 
I don't think it matters that it's being done late in the test cycle.
The new classpath versions are generally so much better than the old
ones, that I think it will be worth it.

I will be wanted to test the libgcj rpm whenever it is released. I was
actually able to build HEAD (4.2) with the 4.1.1 compiler with a few
changes, but then the bins don't look in the right place for the .spec
file, etc. I don't know if that kind of setup is supported anyway, but
at least HEAD already has 0.91 checked in.

- --
Sincerely,

David Walluck
<david(a)zarb.org&gt;
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.3 (GNU/Linux)
> Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org
>
> iD8DBQFEvSzyN5thZBYlTwkRAjz9AJ9JAvjlgDdrScH/SWCW7HU5Y7VKIgCeOm2m
> 3dGfq5M/XCLoTMDO5R0S/xI=
> =wBcS
> -----END PGP SIGNATURE-----

[Tom Tromey]

> >>>> "David" == David Walluck
> <david(a)zarb.org&gt; writes: 
David> Does the ecj branch have any runtime support for generics, or is it just
David> compile-time support?

Mostly just the compile-time support.  It does support some of the new
reflection data, but not annotations, which are the most important
bit.  (Actually much of this support has been written, at least on the
runtime side.  We're really just missing a piece from Classpath... if
we managed to import 0.92 we could fix this up after the release.)

David> I will be wanted to test the libgcj rpm whenever it is released. I was
David> actually able to build HEAD (4.2) with the 4.1.1 compiler with a few
David> changes, but then the bins don't look in the right place for the .spec
David> file, etc. I don't know if that kind of setup is supported anyway, but
David> at least HEAD already has 0.91 checked in.

Bryce back-ported trunk libjava to the 4.1 compiler.  I think this is
in rawhide but I am not completely sure.

Tom

[Mark Wielaard]

Hi,

On Tue, 2006-07-18 at 14:48 -0400, David Walluck wrote:
>  I don't think it matters that it's being done late in the
> test cycle.
>  The new classpath versions are generally so much better than the old
>  ones, that I think it will be worth it. 
Thanks! We are always working hard to make sure every release is only
better and doesn't have bad regressions.

>  I will be wanted to test the libgcj rpm whenever it is released. I
> was
>  actually able to build HEAD (4.2) with the 4.1.1 compiler with a few
>  changes, but then the bins don't look in the right place for the .spec
>  file, etc. I don't know if that kind of setup is supported anyway, but
>  at least HEAD already has 0.91 checked in. 
And there is now a patch for 0.92-pre (hopefully close to 0.92 final)
for HEAD: http://gcc.gnu.org/ml/java/2006-07/msg00057.html
Testers welcome! Hopefully we will be able to backport most of that to
4.1

Cheers,

Mark

[David Walluck]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Mark Wielaard wrote:
>  And there is now a patch for 0.92-pre (hopefully close to 0.92
> final)
>  for HEAD: http://gcc.gnu.org/ml/java/2006-07/msg00057.html
>  Testers welcome! Hopefully we will be able to backport most of that to
>  4.1 
Why is gcjwebplugin being installed to $HOME? This makes no sense as
part of an rpm build. Unfortunately, it just locks my firefox solid on
x86-64, so I would not want it enabled by default in an rpm anyway. (I
did get a message at one point and if I see it again, I will try to post
a bug). It seems to be waiting indefinitely for something and in the
meantime the browser just hangs.

Note also that we should now have gjarsigner and gkeytool in addition to
gappletviewer, so java-1.4.2-gcj-compat should be set up to make slave
symlinks for these three new bins.

- --
Sincerely,

David Walluck
<david(a)zarb.org&gt;
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.3 (GNU/Linux)
> Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org
>
> iD8DBQFEwAR6N5thZBYlTwkRAmuFAJ9AY8KZV/1jcx18izLTBo07xV/WogCeJ2s6
> 9g8YDday+9hmvlYe+CoOtGk=
> =fu6m
> -----END PGP SIGNATURE-----

[Thomas Fitzsimmons]

Hi,

David Walluck wrote:
>  -----BEGIN PGP SIGNED MESSAGE-----
>  Hash: SHA1
>  
>  Mark Wielaard wrote:
> > And there is now a patch for 0.92-pre (hopefully close to 0.92 final)
> > for HEAD: http://gcc.gnu.org/ml/java/2006-07/msg00057.html
> > Testers welcome! Hopefully we will be able to backport most of that to
> > 4.1
>  
>  Why is gcjwebplugin being installed to $HOME? This makes no sense as
>  part of an rpm build. 
What RPM are you building, exactly?

>  Unfortunately, it just locks my firefox solid on
>  x86-64, so I would not want it enabled by default in an rpm anyway. (I
>  did get a message at one point and if I see it again, I will try to post
>  a bug). It seems to be waiting indefinitely for something and in the
>  meantime the browser just hangs. 
Try running gappletviewer standalone, e.g.:

gappletviewer http://thisiscool.com

When the browser hangs like this, it means that gappletviewer is 
misconfigured.  If gappletviewer is not misconfigured then the browser 
will never hang.

>  
>  Note also that we should now have gjarsigner and gkeytool in addition to
>  gappletviewer, so java-1.4.2-gcj-compat should be set up to make slave
>  symlinks for these three new bins. 
See:

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=127537

The libgcj backport, which adds libgcjwebplugin.so and gappletviewer to 
the libgcj RPM for the first time, is building right now; as soon as it 
lands in Rawhide I will release a new version of java-1.4.2-gcj-compat 
that includes java-1.4.2-gcj-compat-plugin.

Tom

[David Walluck]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Thomas Fitzsimmons wrote:
>  What RPM are you building, exactly? 
Sorry, I didn't mean to imply that there was an rpm. I meant that as a
warning for when the new libgcj rpm appears.

>  Try running gappletviewer standalone, e.g.:
>  
>  gappletviewer http://thisiscool.com
>  
>  When the browser hangs like this, it means that gappletviewer is 
>  misconfigured.  If gappletviewer is not misconfigured then the browser 
>  will never hang. 
Running standalone, I get

Exception in thread "main" java.lang.NoClassDefFoundError:
gnu.classpath.tools.appletviewer.Main

tools.zip is supposedly added to the classpath using

- -Xbootclasspath/p:"${tools_cp}"

But gij doesn't support this, at least on the 4.1.1 release I am using
(jamvm works).

>  See:
>  
>  https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=127537
>  
>  The libgcj backport, which adds libgcjwebplugin.so and gappletviewer to 
>  the libgcj RPM for the first time, is building right now; as soon as it 
>  lands in Rawhide I will release a new version of java-1.4.2-gcj-compat 
>  that includes java-1.4.2-gcj-compat-plugin. 
So, how is the plugin installation handled? It seems that the GNU plugin
will override, say, the blackdown plugin for any applets. since the GNU
plugin isn't going through the alternatives system and is just getting
put in the plugin path first. In addition to not liking the configure
for the plugin install location, I don't like how it is looking for
mozilla, when it seems you should also be able to use mozilla-firefox
without problems.

- --
Sincerely,

David Walluck
<david(a)zarb.org&gt;
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.3 (GNU/Linux)
> Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org
>
> iD8DBQFEwBwkN5thZBYlTwkRAu2rAJ99njMI8qM0A8rXtl7dMj6I//ny5QCfUZxE
> IzR8vAa7AmNetwrDhIJiZu4=
> =zClp
> -----END PGP SIGNATURE-----

[Thomas Fitzsimmons]

Hi,

David Walluck wrote:

>  So, how is the plugin installation handled? It seems that the GNU
> plugin
>  will override, say, the blackdown plugin for any applets. since the GNU
>  plugin isn't going through the alternatives system and is just getting
>  put in the plugin path first. In addition to not liking the configure
>  for the plugin install location, I don't like how it is looking for
>  mozilla, when it seems you should also be able to use mozilla-firefox
>  without problems. 
I'm not sure where these assertions are coming from.  What are you 
trying to build/do, exactly?

First, GNU Classpath no longer installs the plugin in ~/.mozilla/plugins 
by default.  Instead, there is an "install-plugin" target in 
$builddir/native/plugin that copies libgcjwebplugin.so to 
~/.mozilla/plugins, if the GNU Classpath developer runs the target 
manually.  This "install-plugin" target is not run by default.

Second, in Red Hat distributions we do use alternatives to manage Java 
plugins.  In the RHEL packages, I introduced the alternatives-managed 
/usr/lib/mozilla/plugins/libjavaplugin.so symlink.  I'll do the same for 
Fedora.  (A long time ago, I proposed this approach to plugin packaging 
to the JPackage maintainers, and provided a patch to java-1.4.2-ibm to 
implement it, but it never made it into the official JPackage packages. 
  I've been discussing it with Daniel though and he thinks it's a good 
idea, so I'm going to try again to have it accepted).

Finally, while GNU Classpath does require the Mozilla headers and 
libraries to build the plugin, so does every Mozilla plugin.  And 
java-1.4.2-gcj-compat-plugin will only require the 
/usr/lib/mozilla/plugins directory, meaning that the plugin will be 
recognized by any browser that supports Netscape plugins.

If you want, add yourself to the CC for this bug:

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=127537

and review java-1.4.2-gcj-compat-plugin after I've committed it.

Tom

[David Walluck]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Thomas Fitzsimmons wrote:
>  I'm not sure where these assertions are coming from.  What are
> you 
>  trying to build/do, exactly?
>  
>  First, GNU Classpath no longer installs the plugin in ~/.mozilla/plugins 
>  by default.  Instead, there is an "install-plugin" target in 
>  $builddir/native/plugin that copies libgcjwebplugin.so to 
>  ~/.mozilla/plugins, if the GNU Classpath developer runs the target 
>  manually.  This "install-plugin" target is not run by default. 
Sorry, again. This isn't a criticism of some rpm in fedora because I
don't know that one exists. Rather, I was talking about the upstream
configure and install process for the plugin. So maybe this is not the
best forum, but if $(libdir)/mozilla/plugins is a more sane location, I
don't see why it doesn't choose that instead of $HOME/.mozilla/plugins.
The comment about firefox is how the plugin is fining the development
headers to build against. I think you are right on how it should work
after it is built, though.

- --
Sincerely,

David Walluck
<david(a)zarb.org&gt;
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.3 (GNU/Linux)
> Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org
>
> iD8DBQFEwET6N5thZBYlTwkRAp09AKCNnVWE0euvnRnavG8VDBXNHKXchQCfUcwJ
> +xQDkzTb6K6wk2NIReCfzFY=
> =QNoW
> -----END PGP SIGNATURE-----