User account creation filtered due to spam.
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):
These exist only in my previous xulrunner directory :
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,
$ /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 \
--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 \
--host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu \
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"
#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
-#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"
See https://developer.mozilla.org/en/firefox_3.6_for_developers :
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.
gcjwebplugin is dead, it should have been removed, but nobody has done that.
Just don't enable it in configure.
Created attachment 24298 [details]
patch to gcjwebplugin.cc to compile against xulrunner-2.0
First attempt that compiles
(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 ?
(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.
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?
(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 .