Subject: CVS commit: pkgsrc/www/firefox
From: Masatake Daimon
Date: 2015-01-30 08:32:24
Message id: 20150130073224.8D1D598@cvs.netbsd.org

Log Message:
Fix many issues on Darwin

PLIST:
  * lib/firefox/libmozglue.so is built and installed as a shared
    library on some platforms including Darwin.

mozilla-common.mk:
  * Sandboxing support is only available when the toolkit is
    cairo-cocoa.
  * It tries to use MacOS X 10.6 SDK by default, which is not always
    possible.

patches/patch-build_gyp.mozbuild:
  * Don't assume iOS just because the toolkit is not cocoa. Ideally
    there should be an AC_SUBST just like 'ARM_ARCH' but nothing
    exists currently.
  * MacOS X SDK version should be able to configure with ./configure
    --enable-macos-target=VER

patches/patch-extensions_spellcheck_hunspell_src_mozHunspell.cpp:
  * NS_NewNativeLocalFile() can fail and leave hunDir null, so we must
    check if it succeeded. This is not Darwin specific though.
  * "%%LOCALBASE%%" in the hunspell path is currently not substituted,
    which looks very erroneous to me. But since I don't know why
    ryoon@ changed it from "@PREFIX@" to "%%LOCALBASE%%" I \ 
leave it as
    it is.

patches/patch-ipc_glue_moz.build:
  * Don't assume cocoa toolkit just because OS_ARCH is Darwin.

patches/patch-js_src_asmjs_AsmJSSignalHandlers.cpp:
  * Increase portability for non-x86 Darwin by not hardwiring
    x86_THREAD_STATE.

patches/patch-js_xpconnect_src_xpcprivate.h:
  * The declaration has to be C++11 'extern template', otherwise
    non-weak symbol collision will occur between libmozjs and
    libxul. We can't easily test if the feature is supported by
    compiler due to GCC bug #1773:
    http://gcc.gnu.org/bugzilla/show_bug.cgi?id=1773

patches/patch-memory_mozalloc_VolatileBufferOSX.cpp:
  * Try to fallback to valloc(3) if posix_memalign(3) is not
    avialble. It has been added since MacOS 10.6.

patches/patch-toolkit_library_moz.build:
  * GSTREAMER_LIBS are linked to libxul on Darwin, while they are
    dlopen(3)'ed at runtime on other platforms. The problem is that
    the toolkit being cocoa isn't relevant at all. It's Darwin that
    needs the special handling, not Cocoa.

patches/patch-toolkit_xre_nsAppRunner.cpp:
  * MacOS X < 10.6 had an undocumented behavior concerning execve(2)
    inside a threaded process. If a process tried to call execve(2)
    and had more than one active thread, the kernel returned
    ENOTSUP. So we have to either fork(2) or vfork(2) before calling
    execve(2) to make sure the caller is single-threaded as otherwise
    the application fails to restart itself.

patches/patch-xpcom_base_nsStackWalk.cpp,
patches/patch-xpcom_build_PoisonIOInterposer.h:
  * Replace XP_MACOSX with XP_DARWIN as the former is not defined when
    the toolkit is not cocoa.

patches/patch-xpcom_glue_standalone_nsXPCOMGlue.cpp:
  * Fix inconsistent use of XP_DARWIN and XP_MACOSX:
    LEADING_UNDERSCORE should be empty when we are going to load XPCOM
    using dlopen(3), not NSAddImage().

Files:
RevisionActionfile
1.92modifypkgsrc/www/firefox/PLIST
1.181modifypkgsrc/www/firefox/distinfo
1.48modifypkgsrc/www/firefox/mozilla-common.mk
1.2modifypkgsrc/www/firefox/patches/patch-build_gyp.mozbuild
1.6modifypkgsrc/www/firefox/patches/patch-extensions_spellcheck_hunspell_src_mozHunspell.cpp
1.2modifypkgsrc/www/firefox/patches/patch-js_xpconnect_src_xpcprivate.h
1.2modifypkgsrc/www/firefox/patches/patch-toolkit_library_moz.build
1.10modifypkgsrc/www/firefox/patches/patch-xpcom_base_nsStackWalk.cpp
1.1addpkgsrc/www/firefox/patches/patch-ipc_glue_moz.build
1.1addpkgsrc/www/firefox/patches/patch-js_src_asmjs_AsmJSSignalHandlers.cpp
1.1addpkgsrc/www/firefox/patches/patch-memory_mozalloc_VolatileBufferOSX.cpp
1.5addpkgsrc/www/firefox/patches/patch-toolkit_xre_nsAppRunner.cpp
1.4addpkgsrc/www/firefox/patches/patch-xpcom_build_PoisonIOInterposer.h
1.3addpkgsrc/www/firefox/patches/patch-xpcom_glue_standalone_nsXPCOMGlue.cpp