Everything should be good, except make install calls find -xtype which is a GNU extension and obviously unavailable on BSD userland. Let's see if we can fix it and finally have xulrunner 1.9 on FreeBSD... $URL is a link to the upstream bug that tracks it, still unfixed unfortunately.
This will not be fixed anytime soon, I will roll a beta of xulrunner soon as we reach beta stages. Until then mozilla upstream and self have not come to a workaround. This has been fixed in 1.9.2 but I will not work with alpha for users.
(In reply to comment #1) > This will not be fixed anytime soon, I will roll a beta of xulrunner soon as we > reach beta stages. Until then mozilla upstream and self have not come to a > workaround. This has been fixed in 1.9.2 but I will not work with alpha for > users. This is probably soon enough. Note that we're talking about a bug that has been around for more than one year...
*** Bug 300918 has been marked as a duplicate of this bug. ***
@BSD: Do you still want this bug open? (aka is there some vague hope that these issues will ever be resolved? :)
(In reply to comment #4) > @BSD: Do you still want this bug open? (aka is there some vague hope that these > issues will ever be resolved? :) > yes
(In reply to comment #5) > (In reply to comment #4) > > @BSD: Do you still want this bug open? (aka is there some vague hope that these > > issues will ever be resolved? :) > > > > yes > When you all get a chance ( soonish ) please test xulrunner from mozilla overlay we will get it moved to tree within the next week or so for user who are wanting to test it out themselves.
(In reply to comment #6) > (In reply to comment #5) > > (In reply to comment #4) > > > @BSD: Do you still want this bug open? (aka is there some vague hope that these > > > issues will ever be resolved? :) > > > > > > > yes > > > > When you all get a chance ( soonish ) please test xulrunner from mozilla > overlay we will get it moved to tree within the next week or so for user who > are wanting to test it out themselves. As no comment has been made, I am removing mozilla team from the bug if later you decide to test and works out for you all, please feel free to re-add your keywords.
Created attachment 304621 [details, diff] xulrunner-2.0.1-r1.patch @mozilla, I have some patch to get it built on Gentoo/FreeBSD. Could you take a look at them please.
Created attachment 304623 [details, diff] xulrunner-2.0.1-freebsd.patch Import from FreeBSD Ports. We have follwing line on <sys/types.h> > #ifndef _INTPTR_T_DECLARED > typedef __intptr_t intptr_t; > typedef __uintptr_t uintptr_t; > #define _INTPTR_T_DECLARED > #endif
(In reply to comment #8) > Created attachment 304621 [details, diff] [details, diff] > xulrunner-2.0.1-r1.patch > > @mozilla, I have some patch to get it built on Gentoo/FreeBSD. Could > you take a look at them please. Please port your work to 10.0.1, use ifdef so the patch can be applied unconditionally. If you can get that all worked out, I will be more then happy to push it upstream for you. We are in the process of getting everything free of xulrunner so we can remove it from tree.
Created attachment 304713 [details, diff] firefox-10.0.1-r1.ebuild.patch
Created attachment 304715 [details] firefox-patch.tar.bz2 Need these 5 patch to build on FreeBSD. I've confirmed patched ebuild could be emerge'd both on FreeBSD and Linux. and .. no need to patch xulrunner for FreeBSD any more? I was working on bug #229427 to KEYWORD gnash.
(In reply to comment #11) > Created attachment 304713 [details, diff] [details, diff] > firefox-10.0.1-r1.ebuild.patch I will review all this soon as I return from work. Thanks for your work on this.
(In reply to comment #12) > and .. no need to patch xulrunner for FreeBSD any more? I was working on bug > #229427 to KEYWORD gnash. Going forward, USE=nsplugin functionality should use net-misc/npapi-sdk instead of xulrunner ... it seems gnash hasn't been converted to that yet, although bug 383071 would seem to imply that it should be...
(In reply to comment #14) > (In reply to comment #12) > > and .. no need to patch xulrunner for FreeBSD any more? I was working on bug > > #229427 to KEYWORD gnash. > > Going forward, USE=nsplugin functionality should use net-misc/npapi-sdk > instead of xulrunner ... it seems gnash hasn't been converted to that yet, > although bug 383071 would seem to imply that it should be... ...sorry, the USE=nsplugin case is handled, the issue is USE=gtk. I'm not sure what the resolution is there but I believe it's a conversion to net-libs/webkit-gtk. There doesn't seem to be a bug opened on this yet but I'll add one shortly.
I will work on these patches Monday for review and inclusion.
Is there a reason this is still open bsd patches have been included in mozilla build in gentoo for quite some time now.
I've just tried to emerge www-client/firefox again, but it failed with the same error as bug #452734 At /var/tmp/portage/www-client/firefox-18.0-r1/work/mozilla-release linux % find . -name 'jemalloc.h' ./obj-x86_64-unknown-linux-gnu/dist/include/jemalloc.h ./obj-x86_64-unknown-linux-gnu/js/src/config/system_wrappers_js/jemalloc.h ./obj-x86_64-unknown-linux-gnu/memory/jemalloc/src/include/jemalloc/jemalloc.h ./obj-x86_64-unknown-linux-gnu/config/system_wrappers/jemalloc.h ./memory/mozjemalloc/jemalloc.h freebsd # find . -name 'jemalloc.h' ./obj-i386-unknown-freebsd9.0/js/src/config/system_wrappers_js/jemalloc.h ./obj-i386-unknown-freebsd9.0/config/system_wrappers/jemalloc.h ./memory/mozjemalloc/jemalloc.h It seems "./obj-*/dist/include/jemalloc.h" is not created on FreeBSD (and prefix) for some reason.
If you feel I have closed your bug and it is still a current issue, please reopen and update it completely. We will not work bugs that have no ebuild in tree any longer or can not be reproduced with a current system. Thank You for your support and understanding The Mozilla Team
