Please update the in portage ebuild for the new release.
Created attachment 131929 [details] ebuild updated Ebuild updated with amd64 support, motif enabled/disabled by useflag.
(In reply to comment #1) > Created an attachment (id=131929) [edit] > ebuild updated > > Ebuild updated with amd64 support, motif enabled/disabled by useflag. > Version 1.19.8 did not compile on amd64 (with ~x86 keyword). With this ebuild I succeeded to build freewrl, but: * I had to enable the motif useflag, * I had to select (java-config) a JDK (instead of JRE) to allow the build procedure to use javac and * the program crashes without any output as soon as I try to load a WRL file.
Created attachment 141726 [details] media-gfx/freewrl-1.20.0 with motif support Version 1.20.0 has been released. This is ebuild for it. It contains optional support for motif user interface. If somebody interests in full screen (root window) support, I have bad message: GCC-4.1.2 complains about doubled type definition in X11/Xmd.h. Thus this feature has not been enabled.
Created attachment 160385 [details] ebuild for latest version Here's an ebuild for the most recent (stable) version of freewrl; just one small change compared to the 1.20 ebuild posted earlier, due to a change in the upstream config file.
Created attachment 162444 [details] Ebuild for latest version Here's an ebuild for freewrl-1.20.5, released Aug.1.2008. I added a patch that fixes QA errors reported by emerge (see next attachment), however it isn't strictly necessary in order to get freewrl to build and run; you can just remove the 'epatch' line in the ebuild if you don't want to use it. Given this bug has been around for quite some time and the current maintainer of freewrl hasn't responded, is this still being maintained? If not, I would like to suggest that it be moved to maintainer-needed status so that users can help keep it alive through sunrise.
Created attachment 162446 [details] patch that fixes QA reports from emerge patch for freewrl-1.20.5 (also applies against 1.20.4) to fix QA error reports. Just add this to your overlay's 'media-gfx/freewrl/files/' dir.
I should've waited another couple of hours -- freewrl-1.20.6 has been released today.. A simple rename of the ebuild (and patch) from 1.20.5 to 1.20.6 installs cleanly on my system.
Created attachment 162527 [details] Ebuild for latest version Made the runtime dependencies into compile-time dependencies (since they are 'detected' at compile-time), and made sound optional via the 'sox' USE flag. I also enforced that either xulrunner or spidermonkey be installed, which takes care of bug #200146. Note, the spidermonkey patch is required for this to work (attached next). As before, the QA patch is optional -- i've submitted it to upstream to see if they're interested in including it.
Created attachment 162529 [details] detect system-installed spidermonkey to avoid compiling its own flavour This patch fixes Makefile.PL so that if spidermonkey (or anything else that provides /usr/bin/js) is installed, then /usr/include/js and libjs.so are used by freewrl instead of it compiling the spidermonkey source included in the archive (libFreeWRLjs.so) Along with fixing bug #200146, it fixed an issue I had with the archive-included spidermonkey when compiling on amd64.
Created attachment 164120 [details] Ebuild replacing virtual/motif with x11-libs/openmotif virtual/openmotif seems beeing removed from portage. At least I missed it on 2008-08-30 and one day before. So this ebuild depeneds on x11-libs/openmotif instead.
Created attachment 164395 [details] Ebuild for latest version New release today. This version depends on x11-libs/openmotif directly (instead of virtual/motif). Pre-stripped binaries are fixed upstream, but the library still lacks a SONAME (so a QA patch is provided to fix this, see below). Default values are now specified for everything in vrml.conf.linux, so I made another patch which undoes these defaults as they're properly auto-detected on config. Also, the Makefile.PL check for a javascript library changed again, and so I updated the spidermonkey patch to check for mozilla-js (xulrunner-1.9), xulrunner-js (ie, 1.8), firefox-js (mozilla-firefox-2.*), and spidermonkey, resorting to compiling the source-included copy of spidermonkey only if all else fails.
Created attachment 164396 [details] Fixes upstream vrml.conf.linux for gentoo necessary patch for the above freewrl-1.20.7.ebuild
Created attachment 164398 [details] patch that fixes QA report (missing SONAME) optional patch used by freewrl-1.20.7.ebuild
Created attachment 164400 [details] Detect system-installed JS libraries to avoid compiling source-included spidermonkey necessary patch to freewrl-1.20.7.ebuild
so, uh, any chance some of these version bumps are going to make it into portage?
(In reply to comment #11) > Created an attachment (id=164395) [edit] > Ebuild for latest version [1.20.7] > > New release today. > For some reason the ebuild have stable x86 keyword instead of unstable one.
Unfortunatelly I'm not able to compile freewrl-1.20.7 against xulrunner-1.9.0.1 having no spidermonkey: gcc -g -O2 -fPIC -I/usr/X11R6/include/ -I/usr/include/freetype2 -I/usr/include/freetype2/freetype -DXP_UNIX -DJS_THREADSAFE -I/usr/include/xulrunner-1.9/stable -I/usr/include/nspr -ICFuncs -ICFrontEnd -fno-stack-protector -ansi -DHAVE_MOTIF -DXP_UNIX -D_GNU_SOURCE -c -o CFuncs/CRoutes.o CFuncs/CRoutes.c CFuncs/CRoutes.c:12:19: error: jsapi.h: no such file or directory However compilation of version 1.20.6 succeeds. xulrunner-1.9.0.1 has jsapi.h under unstable subdirectory (/usr/include/xulrunner-1.9/unstable/jsapi.h).
After searching source code I think current ebuild is to heavy. I found that freewrl uses fontconfig now, so we don't need to install symlink to Bistream Vera fonts (however the font must be installed because the font names are hardcoded into the code). Perl is used at runtime nevermore (see CHANGELOG). Thus some DEPEND items should be moved to RDEPEND variable. Also virtual/jdk is used only at compile time, on run time we need virtual/jre only. Of cource the Java interface is optionable. So JDK and JRE should be qualified by java use flag.
I'll see if I can duplicate the issue you are having with xulrunner-1.9.0.1 and freewrl-1.20.7 -- I've bumped the ebuild to 1.21.0 (no changes other than to the qa patch), but I assume this error you're having will persist. The ebuild is definitely heavy, however I think this will continue to be necessary until freewrl switches to autoconf/automake/configure (which is coming soon).
Created attachment 181699 [details] Ebuild for the first freewrl built with autotools This ebuild is a little lighter than previous ones, and works with freewrl-1.22.0_rc1 (released today or tomorrow). The freewrl release itself may not be as stable as 1.21.x, but please experiment and see how it goes. One thing to note is that freewrl will now link against any mozilla JS library that's available (at least in theory) from xulrunner-1.8/1.9, to the firefox package. This ebuild won't build it against spidermonkey -- a little bit more work needs to be done for that (i'll post the patch next).
Created attachment 181700 [details] patch to compile 1.22.0_rc1 against spidermonkey This file is a patch for the freewrl-1.22.0_rc1 source tarball to allow it to build against spidermonkey. Please also see the next attachment
Created attachment 181701 [details, diff] patch for the ebuild to apply spidermonkey fix This is a patch to freewrl-1.22.0_rc1.ebuild (attachment #181699 [details]) to apply the spidermonkey patch (attachment #181700 [details]) via USE flag.
Are following DEPENDs really necessary at compile time? Couldn't they go into RDEPEND only? media-fonts/ttf-bitstream-vera net-misc/wget media-gfx/imagemagick media-sound/sox Why sox is no more optionable?
Created attachment 182143 [details] error log I'm getting this error. I have xulrunner-1.9.0.6-r1 and mozilla-firefox-3.0.6. Why doesn't it find the xulrunner at configure time?
(In reply to comment #24) > I'm getting this error. > I have xulrunner-1.9.0.6-r1 and mozilla-firefox-3.0.6. > Why doesn't it find the xulrunner at configure time? > It does, but xulrunner's pkg-config file reports bad CFLAGS: # pkg-config --cflags "mozilla-js" -DXP_UNIX -DJS_THREADSAFE -I/usr/include/xulrunner-1.9/stable -I/usr/include/nspr However # find /usr/include/xulrunner-1.9/ -name 'jsapi.h' /usr/include/xulrunner-1.9/unstable/jsapi.h Thus this is bug in xulrunner.
is there a workaround I could use until it's fixed?
I have used ugly fix: --- a/configure.ac +++ b/configure.ac @@ -152,6 +152,9 @@ esac ## if no package yet, test for spidermonkey or other 'js' library if test x$found_JAVASCRIPT_ENGINE = xno; then AC_MSG_ERROR([Unable to find an appropriate javascript engine]) +else + JAVASCRIPT_ENGINE_CFLAGS=$(echo "$JAVASCRIPT_ENGINE_CFLAGS" | sed 's|/stable|/unstable|') + AC_SUBST(JAVASCRIPT_ENGINE_CFLAGS) fi AC_MSG_NOTICE([Using $found_JAVASCRIPT_ENGINE for Javascript engine library]) followed by autoreconf. It allowed me to get next, but stopped on yet another error: i686-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I../.. -Wall -Wundef -Wunused-macros -pthread -I/usr/include/freetype2 -DXP_UNIX -DJS_THREADSAFE -I/usr/include/xulrunner-1.9/unstable -I/usr/include/nspr -I/usr/include/libxml2 -I/usr/include/libpng12 -DTARGET_MOTIF -march=athlon-tbird -O2 -pipe -fomit-frame-pointer -MT x3d_parser/X3DParser.lo -MD -MP -MF x3d_parser/.deps/X3DParser.Tpo -c x3d_parser/X3DParser.c -fPIC -DPIC -o x3d_parser/.libs/X3DParser.o In file included from x3d_parser/X3DParser.c:32: /usr/include/xulrunner-1.9/unstable/expat.h:140: error: expected specifier-qualifier-list before ‘XML_Char’ Browsing through xulrunner's headers I found this: /usr/include/xulrunner-1.9/unstable/expat_external.h: /* BEGIN MOZILLA CHANGE (typedef XML_Char to PRUnichar) */ #if 0 #ifdef XML_UNICODE /* Information is UTF-16 encoded. */ #ifdef XML_UNICODE_WCHAR_T typedef wchar_t XML_Char; typedef wchar_t XML_LChar; #else typedef unsigned short XML_Char; typedef char XML_LChar; #endif /* XML_UNICODE_WCHAR_T */ #else /* Information is UTF-8 encoded. */ typedef char XML_Char; typedef char XML_LChar; #endif /* XML_UNICODE */ #endif /* END MOZILLA CHANGE */ So XML_Char seems undefined because the code has been hidden by Mozilla developers. Current XML_Char typedef is located only in /usr/include/xulrunner-1.9/unstable/expat_config.h, however this file is not included from anywhere and it defines XML_Char as PRUnichar (from /usr/include/nspr/nspr.h from /usr/include/nspr/prtypes.h). But freewrl X3DParser doesn't include nspr.h, so I'm giving patching up. freewrl developers are on the turn. Accually, I wonder how freewrl developers could compile freewrl against xulrunner 1.9.
And yet another patch allowing to find xulrunner-1.9 plugin pkg-config file known as mozilla-plugin on Gentoo: diff --git a/configure.ac b/configure.ac index 618dc4e..f19dd66 100644 --- a/configure.ac +++ b/configure.ac @@ -312,6 +312,7 @@ else AC_MY_CHECK_MODULE(MOZILLA_PLUGIN,xulrunner-plugin) AC_MY_CHECK_MODULE(MOZILLA_PLUGIN,seamonkey-plugin) AC_MY_CHECK_MODULE(MOZILLA_PLUGIN,firefox-plugin) + AC_MY_CHECK_MODULE(MOZILLA_PLUGIN,mozilla-plugin) if test x$found_MOZILLA_PLUGIN = xno; then AC_MSG_WARN([Unable to find an appropriate browser plugin framework, not building plugin]) MAYBE_PLUGIN=
And yet another strange problem after compiling against spidermonkey with motif support: Using getopt_long_only FreeWRL caught an XLib error on Display::0.0 We are just going to ignore error:3 request:19 and continue on FreeWRL caught an XLib error on Display::0.0 We are just going to ignore error:3 request:19 and continue on FreeWRL caught an XLib error on Display::0.0 We are just going to ignore error:3 request:19 and continue on Error: No realize class procedure defined I get this bug on standalone player and on browser plugin. Hower the second case freezes Firefox completely :( I'm downgrading to 1.20.6.
Thanks for finding these and the work you've done on debugging. I'll be uploading new ebuilds and a patch which fixes the xulrunner-1.9 issue (we're still working on it upstream). The mozilla-plugin must have been an oversight and should've been there from the getgo. Finally, the motif bug has been known for a while but as of yet there's no solution and upstream will keep working on it.
SOX isn't optionable right now because the build system doesn't let it be, yet. Also, all of the deps listed here should be RDEPEND only, but right now the build system requires them to exist at compile time too (so they're both). Upstream still has a little ways to go before their build system is perfect. (In reply to comment #23) > Are following DEPENDs really necessary at compile time? Couldn't they go into > RDEPEND only? > media-fonts/ttf-bitstream-vera > net-misc/wget > media-gfx/imagemagick > media-sound/sox > > Why sox is no more optionable? >
Created attachment 182451 [details] Ebuild for freewrl-1.22.0 (rc2) I've uploaded a new ebuild and patchset for freewrl-1.22.0. This one is for rc2, which won't be uploaded onto sourceforge until next week, but i've provided a tarball in the meantime (you can also roll your own snapshot from freewrl CVS if you like). Please download both spidermonkey.patch and xulrunner-19.patch for use with this ebuild. New features: - freewrl will now build against xulrunner-1.9 - mozilla-plugin is detected properly (for FF3) - 'sox' use flag is back - 'spidermonkey' use flag is rolled into the ebuild, no extra modifications needed - 'libeai' use flag provides a new C-based EAI library, and installs the necessary header files for it (and libFreeWRL) in /usr/include/freewrl/ Outstanding bugs: - USE="motif" bug (as mentioned in comment #29) still exists. Please build with USE="-motif" (i know, you lose the menu, it sucks)
Created attachment 182453 [details] spidermonkey patch for 1.22.0_rc2 Please download this for the 1.22.0_rc2 ebuild
Created attachment 182457 [details] fix for xulrunner-1.9 errors with freewrl-1.22.0 Please download this for the 1.22.0_rc2 ebuild
Created attachment 183074 [details] Ebuild for freewrl-1.22.0 (rc2) RC2 was released today and contains a number of fixes. Nearly all issues have been resolved now, I think. I've updated the RC2 ebuild to work with this new version. No patches are necessary. New Features / Fixes: - tested and works with FF3, with OR without xulrunner (note, if FF3 is built with USE="xulrunner", please also build FreeWRL with USE="xulrunner") - tested and works with USE="motif" - added 'debug' USE flag - moved helper apps to RDEPEND The only differences between RC2 and the release version of freewrl-1.22.0 will probably be the addition of java classes. Please let me know if there are any outstanding issues (especially ebuild-related).
(In reply to comment #35) > Created an attachment (id=183074) [edit] > Ebuild for freewrl-1.22.0 (rc2) > It compiles and links fine (USE=motif nsplugin xulrunner): /bin/sh ../../libtool --tag=CC --mode=link i686-pc-linux-gnu-gcc -Wall -Wundef -Wunused-macros -march=athlon-tbird -O2 -pipe -fomit-frame-pointer -Wl,-O1 -o freewrl main.o options.o internal_version.o ../../src/lib/libFreeWRL.la mkdir .libs i686-pc-linux-gnu-gcc -Wall -Wundef -Wunused-macros -march=athlon-tbird -O2 -pip e -fomit-frame-pointer -Wl,-O1 -o .libs/freewrl main.o options.o internal_versio n.o ../../src/lib/.libs/libFreeWRL.so -L/usr/lib/xulrunner-1.9/lib -L/usr/lib/n spr -lmozjs -lplds4 -lplc4 -lnspr4 /usr/lib/libglut.so -L/usr/lib /usr/lib/libGLU.so /usr/lib/libXi.so -lpthread /usr/lib/libGL.so /usr/lib/libXxf86vm.so /usr/lib/libXm.so /usr/lib/libXft.so /usr/lib/libxml2.so /usr/lib/libXrender.so /usr/lib/libfontconfig.so /usr/lib/libexpat.so /usr/lib/libfreetype.so /usr/lib/libjpeg.so /usr/lib/libpng12.so -lz -lm /usr/lib/libXp.so /usr/lib/libXaw7.so /usr/lib/libXpm.so /usr/lib/libXmu.so /usr/lib/libXext.so /usr/lib/libXt.so /usr/lib/libX11.so /usr/lib/libXau.so /usr/lib/libXdmcp.so -ldl /usr/lib/libSM.so /usr/lib/libICE.so creating freewrl However resulting binary can not find libmozjs.so at run time: $ ldd /usr/bin/freewrl linux-gate.so.1 => (0xb7fa0000) libFreeWRL.so.1 => /usr/lib/libFreeWRL.so.1 (0xb7cc6000) * libmozjs.so => not found libplds4.so.7 => /usr/lib/nspr/libplds4.so.7 (0xb7cc2000) libplc4.so.7 => /usr/lib/nspr/libplc4.so.7 (0xb7cbd000) libnspr4.so.7 => /usr/lib/nspr/libnspr4.so.7 (0xb7c88000) libglut.so.3 => /usr/lib/libglut.so.3 (0xb7c54000) libGLU.so.1 => /usr/lib/libGLU.so.1 (0xb7bd2000) libXi.so.6 => /usr/lib/libXi.so.6 (0xb7bc9000) libpthread.so.0 => /lib/libpthread.so.0 (0xb7bb2000) libGL.so.1 => //usr//lib/opengl/nvidia/lib/libGL.so.1 (0xb7b27000) libXxf86vm.so.1 => /usr/lib/libXxf86vm.so.1 (0xb7b22000) libXm.so.4 => /usr/lib/libXm.so.4 (0xb78c2000) libXft.so.2 => /usr/lib/libXft.so.2 (0xb78b0000) libxml2.so.2 => /usr/lib/libxml2.so.2 (0xb778c000) libXrender.so.1 => /usr/lib/libXrender.so.1 (0xb7782000) libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0xb7757000) libexpat.so.1 => /usr/lib/libexpat.so.1 (0xb7736000) libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0xb76b0000) libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0xb7690000) libpng12.so.0 => /usr/lib/libpng12.so.0 (0xb766b000) libz.so.1 => /lib/libz.so.1 (0xb7659000) libm.so.6 => /lib/libm.so.6 (0xb7633000) libXp.so.6 => /usr/lib/libXp.so.6 (0xb762b000) libXaw.so.7 => /usr/lib/libXaw.so.7 (0xb75ce000) libXpm.so.4 => /usr/lib/libXpm.so.4 (0xb75bd000) libXmu.so.6 => /usr/lib/libXmu.so.6 (0xb75a7000) libXext.so.6 => /usr/lib/libXext.so.6 (0xb7599000) libXt.so.6 => /usr/lib/libXt.so.6 (0xb7549000) libX11.so.6 => /usr/lib/libX11.so.6 (0xb7459000) libXau.so.6 => /usr/lib/libXau.so.6 (0xb7455000) libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0xb7450000) libdl.so.2 => /lib/libdl.so.2 (0xb744c000) libSM.so.6 => /usr/lib/libSM.so.6 (0xb7443000) libICE.so.6 => /usr/lib/libICE.so.6 (0xb742b000) libc.so.6 => /lib/libc.so.6 (0xb72fb000) libmozjs.so => not found libstdc++.so.6 => /usr/lib/gcc/i686-pc-linux-gnu/4.1.2/libstdc++.so.6 (0xb7213000) libgcc_s.so.1 => /usr/lib/gcc/i686-pc-linux-gnu/4.1.2/libgcc_s.so.1 (0xb7207000) /lib/ld-linux.so.2 (0xb7fa1000) libGLcore.so.1 => //usr//lib/opengl/nvidia/lib/libGLcore.so.1 (0xb6981000) libnvidia-tls.so.1 => //usr//lib/opengl/nvidia/lib/libnvidia-tls.so.1 (0xb697e000) This is beacause libmozjs.so is located in: net-libs/xulrunner (/usr/lib/xulrunner-1.9/sdk/lib/libmozjs.so) net-libs/xulrunner (/usr/lib/xulrunner-1.9/libmozjs.so) and -L/usr/lib/xulrunner-1.9/lib from libtool is link to /usr/lib/xulrunner-1.9/sdk/lib. However no proper path is in /etc/ld.so.conf on my Gentoo. I don't know what's wrong. Wheteher xulrunner (ld.so.conf) or some libtool stuff in this freewrl release. Just FYI, this relase works fine with explicit LD_LIBRARY_PATH.
The error is from some missing libtool stuff in freewrl -- I was adding it via patch but when I loved things over to environment variables (so that the ebuild doesn't have to autoreconf) I forgot to specify the extra LDFLAG for xulrunner. Technically, libraries for xulrunner are supposed to be loaded via XPCOM_GLUE instead of being linked to, which I am guessing is why none of the xulrunner libs are in LDPATH. I'll be uploading a fixed ebuild in a few hours, after i've had a chance to test it.
Created attachment 183143 [details] Ebuild for freewrl-1.22.0 (rc2) Ebuild which adds --rpath fix for xulrunner, as promised. Also, I apologize for not having the "${S}" set properly -- i'm leaving it at default because upstream is going to fix it, but until that happens just add this line: S="${WORKDIR}/${PN}-${PV/rc4/rc2}"
It works very well now. If I could have a request, would it be possible to include manual <http://freewrl.sourceforge.net/freewrl.html> to the tar ball? Current release doesn't cover manual with key binding.
I think the plan upstream is to have a manpage -- i'm sure the final release will include something, though. One thing to note is that the command-line options have changed (so the document at that url is actually obsolete right now)
Created attachment 188309 [details] Ebuild for freewrl-1.22.1 (rc1) New release this week -- some development is still in progress, but here's a ebuild for it. 'libeai' use flag was removed as libEAI is currently broken. As soon as it's fixed i'll add the flag back. Otherwise everything is pretty much the same. Still no manpage or other documentation included in this release.
Created attachment 189874 [details] Ebuild for freewrl-1.22.2 (rc1) New release today -- libeai is back again, and some minor changes to command-line options. Still no manpage or documentation though. On my system (xorg-1.5, intel) it seems very stable, even the firefox plugin is working out-of-the-box every time right now. If hanno or any other dev wants to update portage, this would be a good one to use (although another release snapshot is coming in ~2 weeks)..
Created attachment 193517 [details] Ebuild for freewrl-1.22.3 New version released today -- here's the update. There's an official API for libEAI now, so I removed the custom include-file installation from the ebuild. I also enabled some default USE flags (like motif, without it there's no menu).
(In reply to comment #43) > Created an attachment (id=193517) [edit] > Ebuild for freewrl-1.22.3 > > New version released today -- here's the update. Hi! When trying to emerge this ebuild (1.22.3), I get this error: In file included from main/MainLoop.c:13: ./system_js.h:23:50: error: ../unstable/jsapi.h: No such file or directory ./system_js.h:24:53: error: ../unstable/jsdbgapi.h: No such file or directory The full build log is at http://pastebin.com/m7547eb38 This is my first try to install FreeWRL, so I'm sorry if I'm doing something wrong. Tomas > > There's an official API for libEAI now, so I removed the custom include-file > installation from the ebuild. I also enabled some default USE flags (like > motif, without it there's no menu). >
(In reply to comment #44) > Hi! > When trying to emerge this ebuild (1.22.3), I get this error: > > In file included from main/MainLoop.c:13: > ./system_js.h:23:50: error: ../unstable/jsapi.h: No such file or directory > ./system_js.h:24:53: error: ../unstable/jsdbgapi.h: No such file or directory > Hi Tomas -- what version of firefox and/or xulrunner do you have installed? Also, which USE flags are enabled when you build freewrl? Ian
Hi Ian, I have Firefox 3.0.10 and versions 1.8.1.19 (/usr/bin/xulrunner) and 1.9.0.10 (/usr/bin/xulrunner-1.9) of xulrunner installed. freewrl has the following USE flags: USE="motif nsplugin sox -debug -libeai -spidermonkey -static -xulrunner"
(In reply to comment #46) > Hi Ian, > I have Firefox 3.0.10 and versions 1.8.1.19 (/usr/bin/xulrunner) and 1.9.0.10 > (/usr/bin/xulrunner-1.9) of xulrunner installed. > freewrl has the following USE flags: > USE="motif nsplugin sox -debug -libeai -spidermonkey -static -xulrunner" > The error is probably because you have xulrunner-1.9 installed (and firefox-3 was probably built against it), but the xulrunner USE flag is disabled for freewrl. Try enabling it and see if that works for you. I'll do some research to see what I can do about ensuring this error doesn't happen again..
Created attachment 194173 [details] Updated ebuild for freewrl-1.22.3 I added a check to ensure that the "xulrunner" use flag matches between freewrl and firefox-3. I also fixed a few other dependency errors that had slipped through the cracks.
(In reply to comment #47) > (In reply to comment #46) > > Hi Ian, > > I have Firefox 3.0.10 and versions 1.8.1.19 (/usr/bin/xulrunner) and 1.9.0.10 > > (/usr/bin/xulrunner-1.9) of xulrunner installed. > > freewrl has the following USE flags: > > USE="motif nsplugin sox -debug -libeai -spidermonkey -static -xulrunner" > > > > The error is probably because you have xulrunner-1.9 installed (and firefox-3 > was probably built against it), but the xulrunner USE flag is disabled for > freewrl. Try enabling it and see if that works for you. This fixed the problem, thank you!
(In reply to comment #48) > Created an attachment (id=194173) [edit] > Updated ebuild for freewrl-1.22.3 > > I added a check to ensure that the "xulrunner" use flag matches between freewrl > and firefox-3. I also fixed a few other dependency errors that had slipped > through the cracks. > I would suggest to inherit autotools.eclass to make sure we have the latest versions of required autotools components.
(In reply to comment #50) > > I would suggest to inherit autotools.eclass to make sure we have the latest > versions of required autotools components. > I'd rather not, unless/until the build system needs to be patched (and i'm working closely with upstream to ensure that it doesn't). As it stands now, there wouldn't be any benefit to patching the build system, thus no benefit to running eautoreconf (that I can see). Afaik, the package as it stands now doesn't need any autotools stuffs installed at all, does it?
(In reply to comment #51) > (In reply to comment #50) > > > > I would suggest to inherit autotools.eclass to make sure we have the latest > > versions of required autotools components. > > > > I'd rather not, unless/until the build system needs to be patched (and i'm > working closely with upstream to ensure that it doesn't). As it stands now, > there wouldn't be any benefit to patching the build system, thus no benefit to > running eautoreconf (that I can see). Afaik, the package as it stands now > doesn't need any autotools stuffs installed at all, does it? > It's not for patching but to ensure we have at least the versions of autoconf, libtool and automake. * autoconf version >= 2.60. * libtool version >= 2.0. * automake version >= 1.10. Where at least the needed libtool is in ~arch.
(In reply to comment #52) > (In reply to comment #51) > > It's not for patching but to ensure we have at least the versions of autoconf, > libtool and automake. > > * autoconf version >= 2.60. > * libtool version >= 2.0. > * automake version >= 1.10. > > Where at least the needed libtool is in ~arch. > ..I still don't follow. The freewrl release tarball contains pre-built build scripts; we don't need autoconf, libtool, or automake installed. autotools.eclass says that it's for regenerating the build scripts, and since we have no need to patch the build scripts, what need to we have to regenerate them? Further, freewrl doesn't need anything special to regenerate the build scripts: >=automake-1.10 (1.9 also works w/o modification, but complains some), >=libtool-1.5.26, >=autoconf-2.60 -- all are available in +arch and have been for a long time.
Created attachment 199355 [details] Updated ebuild for freewrl-1.22.4 A new release is hitting the freewrl mirrors in the next day or so. Not much has changed, mainly bugfixes. CURL support has been added as an alternative to using wget, and although this functionality is very new I added a use flag to enable the option at compile time. For the ebuild, I changed the use flag handling around a little bit, including enabling USE="xulrunner" by default (which matches the default for firefox-3). This allowed for the removal of the die on mismatched USE="xulrunner" values between firefox and freewrl (and so everyone that doesn't play with use flags can just emerge it and be done with it). Hopefully someone can get this one into portage soon? bonsaikitten?
I've upgraded xulrunner to 1.9.1 because of mozilla-firefox-3.5 and now freewrl-1.22.4[motif nsplugin xulrunner] does not compile: i686-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I../.. -Wall -Wundef -Wunused-macros -I/usr/include/freetype2 -DXP_UNIX -DJS_THREADSAFE -I/usr/include/xulrunner-1.9.1/unstable -I/usr/include/nspr -I/usr/include/libxml2 -I/usr/include/libpng12 -DTARGET_MOTIF -Wall -Wundef -Wunused-macros -fno-strict-aliasing -march=athlon-tbird -O2 -pipe -fomit-frame-pointer -MT x3d_parser/X3DParser.lo -MD -MP -MF x3d_parser/.deps/X3DParser.Tpo -c x3d_parser/X3DParser.c -fPIC -DPIC -o x3d_parser/.libs/X3DParser.o In file included from /usr/include/xulrunner-1.9.1/unstable/jspubtd.h:99, from /usr/include/xulrunner-1.9.1/unstable/jsapi.h:49, from ./system_js.h:26, from x3d_parser/../world_script/JScript.h:13, from x3d_parser/X3DParser.c:23: /usr/include/xulrunner-1.9.1/unstable/jsproto.tbl:69:5: warning: "JS_HAS_FILE_OBJECT" is not defined
Hi Petr -- the message you pasted is actually just a warning, and has existed for all compilations against xulrunner-1.9.. However, i would not be surprised if there was an error when compiling against >=xulrunner-1.9.1 as I don't test against ~arch, and i'll check it out as soon as get my updated dependencies installed.
My fault, I forgot to copy rest of the messages. The warning is followed by: In file included from x3d_parser/X3DParser.c:36: /usr/include/xulrunner-1.9.1/unstable/expat.h:140: error: expected specifier-qualifier-list before ‘XML_Char’ It looks like my comment #27.
Ahh, goodie. That mozilla-bundled-expat vs. system expat issue again.. OK, I've got a probable fix sent upstream, hopefully they'll update the source tarball; otherwise it'll have to wait until 1.22.5 and i'll put a patch up here in the meantime. Alternatively, you can fix it by editing /usr/lib/pkgconfig/mozilla-js.pc and changing 'unstable' to 'stable'
Created attachment 199558 [details] Patch to fix compile error on newer xulrunner's OK, I don't think upstream is going to re-bundle 1.22.4, so in the meantime this patch and the following ebuild will fix the compile issues with >=xulrunner-1.9.0.11
Created attachment 199560 [details] Ebuild that applies the ff35 patch Use this ebuild with the patch in attachment 199558 [details]
Unfortunately not: depbase=`echo world_script/jsUtils.lo | sed 's|[^/]*$|.deps/&|;s|\.lo$||'`;\ /bin/sh ../../libtool --tag=CC --mode=compile i686-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I../.. -Wall -Wundef -Wunused-macros -I/usr/include/freetype2 -DXP_UNIX -DJS_THREADSAFE -I/usr/include/xulrunner-1.9.1/stable -I/usr/include/nspr -DMOZILLA_JS_UNSTABLE_INCLUDES -I/usr/include/libxml2 -I/usr/include/libpng1 2 -DTARGET_MOTIF -Wall -Wundef -Wunused-macros -fno-strict-aliasing -march=athlon-tbird -O2 -pipe -fomit-frame-pointer -MT world_script/jsUtils.lo -MD -MP -MF $depbase.Tpo -c -o world_script/jsUtils.lo world_script/jsUtils.c &&\ mv -f $depbase.Tpo $depbase.Plo i686-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I../.. -Wall -Wundef -Wunused-macros -I/usr/include/freetype2 -DXP_UNIX -DJS_THREADSAFE -I/usr/include/xulrunner-1.9.1/sta ble -I/usr/include/nspr -DMOZILLA_JS_UNSTABLE_INCLUDES -I/usr/include/libxml2 -I/usr/include/libpng12 -DTARGET_MOTIF -Wall -Wundef -Wunused-macros -fno-strict-aliasin g -march=athlon-tbird -O2 -pipe -fomit-frame-pointer -MT world_script/jsUtils.lo -MD -MP -MF world_script/.deps/jsUtils.Tpo -c world_script/jsUtils.c -fPIC -DPIC -o world_script/.libs/jsUtils.o In file included from /usr/include/xulrunner-1.9.1/stable/../unstable/jspubtd.h:99, from /usr/include/xulrunner-1.9.1/stable/../unstable/jsapi.h:49, from ./system_js.h:23, from world_script/jsUtils.h:21, from world_script/jsUtils.c:31: /usr/include/xulrunner-1.9.1/stable/../unstable/jsproto.tbl:69:5: warning: "JS_HAS_FILE_OBJECT" is not defined world_script/jsUtils.c: In function ‘JS_DefineSFNodeSpecificProperties’: world_script/jsUtils.c:976: error: ‘JSPROP_EXPORTED’ undeclared (first use in this function) world_script/jsUtils.c:976: error: (Each undeclared identifier is reported only once world_script/jsUtils.c:976: error: for each function it appears in.) make[3]: *** [world_script/jsUtils.lo] Error 1 Seems like some header files from unstable leek into stable directory.
Yeah, they have to -- in xulrunner-1.9, jsapi.h is an unstable header, but one cannot -I the unstable directory because xulrunner has a hacked-to-death expat bundled in it (which is the cause of the error of comment 57). JSPROP_EXPORTED is a #define that exists in jsapi.h for spidermonkey-1.7 and xulrunner-1.8 through 1.9.0.11 ....i'm going to have to investigate what happened to it. At the moment it looks like freewrl isn't going to compile against xulrunner-1.9.1
Created attachment 199571 [details] Patch to fix compile errors on newer xulrunner's Ok, this patch fixes the compile errors for libfreewrl. unfortunately there are much more serious compile errors in the plugin code, which this does not fix. You'll need to emerge with USE="-nsplugin" for >=xulrunner-1.9.1
Created attachment 199573 [details] Ebuild that applies the ff35 patch I uploaded the wrong attachment the first time, sorry.
Thanks for investigation. It compiles fine without nsplugin. BTW, EAPI 2 introduced new ebuild funtion src_prepare() that can be used patching wihtou explicit source unpacking: --- freewrl-1.22.4-r1.ebuild.old 2009-07-29 20:10:41.000000000 +0200 +++ freewrl-1.22.4-r1.ebuild 2009-07-29 20:09:23.000000000 +0200 @@ -51,9 +51,7 @@ fi } -src_unpack() { - unpack ${A} - cd "${S}" +src_prepare() { epatch "${FILESDIR}/${P}-ff35.patch" eautoreconf }
Created attachment 199590 [details] Patch to fix compile errors on newer xulrunner's Updated the patch to include the necessary changes to get the plugin compiling. It looks like everything will work but as I don't have FF3.5 installed I can't check.
It compiles now fine and works initially. However the plugin crashes after destroying them (e.g. on web page reload): FreeWRL - too many XLib errors, exiting... Locking assertion failure. Backtrace: #0 /usr/lib/libxcb-xlib.so.0 [0xb73b3856] freewrl: xcb_xlib.c:73: xcb_xlib_lock: Assertion `!c->xlib.lock' failed. Don't struggle with it. Firefox 3.5 crashes with (outdated) Gnash-0.8.4 on different error too. Something smells there.
(In reply to comment #67) > It compiles now fine and works initially. However the plugin crashes after > destroying them (e.g. on web page reload): […] > Don't struggle with it. Firefox 3.5 crashes with (outdated) Gnash-0.8.4 on > different error too. Something smells there. > This is not true since mozilla-firefox-3.5.1 (and appropriate xulrunner) any more. Both freewrl and gnash works very well. It was bug in firefox probably.
Created attachment 206123 [details] Updated ebuild for freewrl-1.22.5 Freewrl 1.22.5 was released this weekend; changes include more shader support and a forthcoming release for Windows. This package has been compile-tested against firefox-3.5 and cleanly compiles both the binary and the plugin, but no runtime tests have been performed so please leave feedback if you have FF35. Even if there are bugs, I'm going to try and get this version into the portage tree as it's still multiple orders of magnitude better than what's there now.
+ 05 Oct 2009; Patrick Lauer <patrick@gentoo.org> +freewrl-1.22.5.ebuild, + metadata.xml: + Bump to 1.22.5, fixes #192840. Thanks to Ian Stakenvicius for the updated + ebuild
