User account creation filtered due to spam.

Bug 49077 - gcjwebplugin.cc doesn't compile against latest xulrunner 2.0 (firefox-3.6) sdk
Summary: gcjwebplugin.cc doesn't compile against latest xulrunner 2.0 (firefox-3.6) sdk
Status: UNCONFIRMED
Alias: None
Product: gcc
Classification: Unclassified
Component: java (show other bugs)
Version: 4.6.0
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-05-20 09:50 UTC by Jason Vas Dias
Modified: 2011-05-20 18:47 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed:


Attachments
patch to gcjwebplugin.cc to compile against xulrunner-2.0 (1011 bytes, patch)
2011-05-20 11:19 UTC, Jason Vas Dias
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Jason Vas Dias 2011-05-20 09:50:39 UTC
When attempting to build gcc-4.6.0 with libjava, AWT peers, and browser plugin,
 gcjwebplugin.cc does not compile because these headers are missing from
 xulrunner-2.0b13 (the latest stable mozilla build, but checked out out from HG):
   nsIPluginInstancePeer.h
   nsIPluginTagInfo2.h
 These exist only in my previous xulrunner directory :
  /usr/include/xulrunner-1.9.0.12pre/unstable/nsIPluginInstancePeer.h
 I don't think the gappletviewer should be choosing to use the 'unstable' API !
Since I've removed the old versions of xulrunner, I'll have to port gappletviewer
to use the new xulrunner API, and will post patch here when done, unless someone
has already done it ? If so, please post patch or tell me where I can find one.
Thanks & Regards,
Jason
Comment 1 Jason Vas Dias 2011-05-20 10:07:20 UTC
my config:

  $ /usr/build2/gcc/gcc-4.6.0/configure --prefix=/usr --libdir=/usr/lib64\
    --with-cpu-32=i686 --with-cpu-64=k8 --enable-languages=all \
    --enable-targets=all --enable-multilib --enable-threads=posix --enable-tls\
    --enable-lto --enable-shared --enable-checking=release \
    --with-build-time-tools=/usr/bin --with-ld=/usr/bin/ld --with-gnu-ld \
    --with-as=/usr/bin/as --with-gnu-as --enable-__cxa_atexit \
    --disable-libunwind-exceptions --with-gxx-include-dir=/usr/include/c++\
    --enable-version-specific-runtime-libs --with-system-zlib --disable-werror\
    --enable-classpath --with-x --enable-gtk-cairo --enable-java-awt=gtk,xlib\
    --withjava-home=/usr/java --with-jvm-root-dir=/usr/java/jvm \
    --with-jvm-jar-dir=/usr/java/jvm_exports --enable-browser-plugin\ 
    --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu \
    --without-included-gettext --enable-serial-configure

with /usr/build2/gcc/gcc-4.6.0 containing GCC source identical to that shipped
in gcc-4.6.0.tar.bz2 except for this patch which I use for my distro defaults :

diff -up gcc/config/i386/linux.h~ gcc/config/i386/linux.h
--- gcc/config/i386/linux.h~    2011-01-14 18:45:06.000000000 +0000
+++ gcc/config/i386/linux.h     2011-04-05 22:17:10.000000000 +0100
@@ -92,7 +92,7 @@ along with GCC; see the file COPYING3.

 /* These macros may be overridden in k*bsd-gnu.h and i386/k*bsd-gnu.h. */
 #define LINK_EMULATION "elf_i386"
-#define GLIBC_DYNAMIC_LINKER "/lib/ld-linux.so.2"
+#define GLIBC_DYNAMIC_LINKER "/lib32/ld-linux.so.2"

 #undef  ASM_SPEC
 #define ASM_SPEC \
diff -up gcc/config/i386/linux64.h~ gcc/config/i386/linux64.h
--- gcc/config/i386/linux64.h~  2011-03-02 22:35:36.000000000 +0000
+++ gcc/config/i386/linux64.h   2011-04-05 22:17:33.000000000 +0100
@@ -62,7 +62,7 @@ see the files COPYING3 and COPYING.RUNTI
    When the -shared link option is used a final link is not being
    done.  */

-#define GLIBC_DYNAMIC_LINKER32 "/lib/ld-linux.so.2"
+#define GLIBC_DYNAMIC_LINKER32 "/lib32/ld-linux.so.2"
 #define GLIBC_DYNAMIC_LINKER64 "/lib64/ld-linux-x86-64.so.2"

 #if TARGET_64BIT_DEFAULT
Comment 2 Jason Vas Dias 2011-05-20 10:17:10 UTC
See https://developer.mozilla.org/en/firefox_3.6_for_developers :

"Interfaces merged

The following interfaces have been combined together:

    nsIPluginTagInfo2 has been merged into nsIPluginTagInfo.
    nsIPluginInstanceInternal, nsIPPluginInstancePeer, nsIPluginInstancePeer1, nsIPluginInstancePeer2, and nsIPluginInstancePeer3 have all been merged into nsIPluginInstance.
    nsIWindowlessPlugInstPeer has been merged into nsIPluginInstance.
    nsIPluginManager and nsIPluginManager2 have been merged into nsIPluginHost.

"
Comment 3 Jakub Jelinek 2011-05-20 11:00:28 UTC
gcjwebplugin is dead, it should have been removed, but nobody has done that.
Just don't enable it in configure.
Comment 4 Jason Vas Dias 2011-05-20 11:19:25 UTC
Created attachment 24298 [details]
patch to gcjwebplugin.cc to compile against xulrunner-2.0

First attempt that compiles
Comment 5 Jason Vas Dias 2011-05-20 12:56:44 UTC
(In reply to comment #3)
> gcjwebplugin is dead, it should have been removed, but nobody has done that.
> Just don't enable it in configure.

Well then what replaces the Firefox plugin functionality - ie.
what happens when I include '--enable-browser-plugin' in configure args ?
A JVM environment and Java SDK is hardly worthy of the name unless it
can be used to run java applets embedded in webpages from the system
browser - how else is one meant to do this using only GCJ components ?

This problem appears to be the ONLY reason gcjwebplugin fails to build ;
are you sure rumors of its demise are not premature ?
Comment 6 Jakub Jelinek 2011-05-20 13:15:15 UTC
(In reply to comment #5)
> (In reply to comment #3)
> > gcjwebplugin is dead, it should have been removed, but nobody has done that.
> > Just don't enable it in configure.
> 
> Well then what replaces the Firefox plugin functionality - ie.
> what happens when I include '--enable-browser-plugin' in configure args ?
> A JVM environment and Java SDK is hardly worthy of the name unless it
> can be used to run java applets embedded in webpages from the system
> browser - how else is one meant to do this using only GCJ components ?
> 
> This problem appears to be the ONLY reason gcjwebplugin fails to build ;
> are you sure rumors of its demise are not premature ?

It is what the gcjwebplugin authors told me when I reported it to them many months ago.  The plugin is maintained as part of icedtea for openjdk, and that's where development and maintainance occurs.
Comment 7 Andrew John Hughes 2011-05-20 13:34:43 UTC
gcjwebplugin in gcj/Classpath is dead.  I actually suggested it be removed some time ago, but there was resistance to doing so.  Current development on a Free Software browser plugin takes place in the IcedTea-Web project, but this currently supports only IcedTea as the JDK.  I'd like to see it eventually support gcj too, but it would need work on both sides for this to happen.

As to your comment about a JDK being irrelevant without applet support, I think most enterprise JDK users would take issue with this; there is plenty of use for a JDK besides running applets.  OpenJDK itself (as provided by Oracle) doesn't have applet support, hence the need for the IcedTea-Web project to provide a Free implementation.

BTW, regarding the subject, isn't xulrunner 2.0 firefox 4.0, not 3.6?
Comment 8 Jason Vas Dias 2011-05-20 18:47:00 UTC
(In reply to comment #7)
> this currently supports only IcedTea as the JDK.  I'd like to see it eventually
> support gcj too, but it would need work on both sides for this to happen.
> 
> OpenJDK itself (as provided by Oracle) doesn't have applet support, 
> hence the need for the IcedTea-Web project to provide a Free implementation.

IMHO, also hence the need to maintain gappletbrowser + gcjwebplugin in the
interim .  Why must I install yet another whole subsystem just to get 
a java applet displaying in my browser with GCJ + libjava, when it
used not to require one ?  
If gappletbrowser + gcjwebplugin is so thoroughly deprecated, then
gcc's configure should refuse to accept the '--enable-browser-plugin'
option, or, if it does accept it, something like the patch attached
to this bug must be applied to enable the browser plugin to compile.

> 
> BTW, regarding the subject, isn't xulrunner 2.0 firefox 4.0, not 3.6?


Yes, I am building against firefox-4.0 / xulrunner-2.0 but the same problem 
will occur if user try to '--enable-browser-plugin' against firefox-3.6 SDK,
because as Comment #2 shows, they removed the nsIPluginTagInfo2 interface
in firefux-3.6 .