${MAKE} bootstrap: Build bootkits with -static-libgcc

We don't want our bootkits to have a run-time dependency on libgcc. In
fact GHC's implementation of Haskell exception handling does not
depend on libgcc's facilities so it is attractive to do the same for
"normal" build... but we can't. This is because Haskell programs may
call C functions via FFI, and those C functions may call C++ functions
in turn, possibly in a different shared library.

But on some platforms, gcc automagically inserts a dependency on a
shared libgcc when -lpthread is given, which is seemingly unavoidable.

(pho)

patches/patch-rts_ghc.mk: dtrace hack is no longer needed

The problem only occurs when $(WhatGccIsCalled) is an absolute path to
the "real" gcc (e.g. "/usr/bin/gcc"), which happens if we run
${WRKSRC}/configure with an option something like
"--with-gcc=/usr/bin/gcc". As long as we use "--with-gcc" with a
command name (i.e. ${CC}, not ${CCPATH}), everything works fine
without any problems.

This is because dtrace(1) executes cpp in a rather weird way: it calls
execvp("/usr/bin/gcc", argv) with argv set to {"gcc", "-E", "-xc",
...}, not {"/usr/bin/gcc", "-E", "-xc", ...}.

When GCC is called that way, it needs to find platform-specific
subprograms by walking through ${PATH}. And if it sees an executable
named "gcc" which in fact isn't actually gcc, it gets confused and
dies with an error:

  % cat dtrace-emu.c
  #include <unistd.h>
  #include <stdio.h>
  int main() {
      char *argv[] = {"gcc", "-E", NULL};
      execvp("/usr/bin/gcc", argv);
      return 0;
  }
  % gcc dtrace-emu.c -o /tmp/gcc
  % /tmp/gcc
  powerpc-apple-darwin9-gcc-4.0.1: no input files
  % PATH=/tmp/gcc /tmp/gcc
  gcc: installation problem, cannot exec '/tmp/powerpc-apple-darwin9-gcc-4.0.1':
  No such file or directory

And even if the problem should really be addressed, it should be done
in the wrapper framework because dtrace(1) is actually a part of
compiler toolchain.

(pho)

patches/patch-rts_ghc.mk: Fix build failure on Darwin

See the comment for details.

(pho)

Add upstream Trac URL to patches/patch-rts_StgCRun.c

(pho)

Add comments

(pho)

${MAKE} bootstrap: Be more verbose about what we've built

The "bootstrap" target now prints a message about run-time
dependencies of the bootkit you've just built, something like:

==========================================================================
Done creating ghc-7.6.3-boot-x86_64-unknown-netbsd.tar.xz
  in /usr/pkgsrc/lang/ghc7/work

Now you can copy it into /usr/pkgsrc/distfiles/ to use it as your
bootstrap kit. You may want to take a backup in case "lintpkgsrc -r"
removes it.

Your bootstrap kit has the following run-time dependencies:
  * curses:  native (version/variant unknown)
  * iconv:  native (version/variant unknown)
==========================================================================

(pho)

Ensure that BUILDLINK_PKGNAME.curses is always defined.

(pho)

lang/ghc7 no longer requires ${PREFIX}/lib to be put into /etc/ld-elf.so.conf

The installed GHC has already been working without the ld hack. These
changes should only affect the package build so revbump isn't needed.

Makefile (CONFIGURE_ENV):
  Refactored with no semantic changes.

Makefile (post-patch):
  ${WRKSRC}/libraries/base/configure.ac is patched too.

Makefile (CHECK_SHLIBS_SUPPORTED):
  Removed the variable as the package now supports it.

Makefile (CHECK_SHLIBS_SKIP):
  Added to skip checks for dynamic Haskell libraries. See the comment
  for details.

bootstrap.mk (pre-configure):
  Use ${CONFIGURE_ENV} when configuring the stage-0 compiler. See the
  comment for details.

patches/patch-libraries_base_configure.ac:
  Added to prevent {CPP,LD}FLAGS from being clobbered. See the comment
  for details. I will send the patch to the upstream in a few days or
  weeks (or even months, depending on my busyness).

(pho)

Fix build failure that occurs when pkgsrc devel/ncurses is being used

* Formerly we were passing
  "--with-curses-includes=${BUILDLINK_PREFIX.curses}/include" to
  "${WRKSRC}/libraries/terminfo/configure". This is problematic
  because pkgsrc devel/ncurses installs headers into
  ${PREFIX}/include/ncurses, not ${PREFIX}/include, while ghc-cabal
  expects "ncurses.h" and "term.h" in ${PREFIX}/include (because we
  said so) and then it emits an error. The fix is to use
  ${BUILDLINK_INCDIRS.curses} instead of "include". Note that this
  requires my recent changes to ../../mk/curses.buildlink3.mk (r1.21)

* The "bootstrap" target now uses buildlink wrapper not to pick up
  random libraries which happened to be in "${PREFIX}/lib". Bootstrap
  binary kits should be linked with a predictable set of libraries.

* The "bootstrap" target now automatically runs through the wrapper
  phase. You no longer have to run "${MAKE} patch" manually.

(pho)

Ensure BUILDLINK_{INCDIRS,LIBDIRS}.curses are always defined

These variables are for packages where populating -I/-L flags into
{C,CPP,LD}FLAGS is not enough and need to know accurate paths to
header and library directories.

This is particularly important for ncurses because its headers
sometimes reside in "${BUILDLINK_PREFIX.ncurses}/include/ncurses" and
sometimes in "${BUILDLINK_PREFIX.ncurses}/include" while no pkg-config
.pc files are available. The same goes for ncursesw.

(pho)

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().

(pho)

PLIST: Add a missing file

"share/appdata/evince-dvidocument.metainfo.xml" gets installed when the dvi option is enabled.

(pho)

Fix build failure on Darwin when pkgsrc libiconv is used

patches/patch-src_portable__c.c:
  Remove kludge for MacPorts bug, otherwise linking against pkgsrc
  libiconv will fail due to symbol name mismatch.

patches/patch-tmake_lib_macosx-c++_tmake.conf:
  Make build honor PKGSRC_CFLAGS, otherwise linking against pkgsrc
  libiconv will fail due to header/library mismatch.

(pho)

Makefile: Fix indentation in my previous commit

(pho)

patches/patch-src_util_Alloc.{c,h}xx: Add a note that the revised patch has also been rejected.

The upstream is not willing to accept any patches to fix build failures on outdated platforms, regardless of whether the patch is rational or not.

(pho)

patches/patch-src_system_Clock.cxx: Avoid integer overflow in MonotonicClock{S,MS,US}

This is Darwin specific: the original implementation was causing an
integer overflow when base.numer was very large. On PPC Darwin, the
timebase is 1000000000/33330116 and this is too large for integer
arithmetic.

http://bugs.musicpd.org/view.php?id=4292

(pho)

patches/patch-src_util_Alloc.{cxx,hxx}: Add upstream bug report URL

The previous report 4289 was rejected as the upstream doesn't have interest in Darwin support. I created a better patch and sent it to the upstream to see if it has any chance to be merged.

(pho)

Fix build failures on Darwin

patches/patch-src_output_plugins_httpd_HttpdOutputPlugin.cxx:
  Resurrected from the Attic and added some comment.

patches/patch-src_util_Alloc.cxx,
patches/patch-src_util_Alloc.hxx:
  Some platforms (e.g. Darwin 9) don't have strndup(3), but the function
  xstrndup() isn't used in the first place.

(pho)

Long double math functions are not available on Darwin.

See boost/math/tools/config.hpp:53

(pho)

patches/patch-libs_context_src_asm_make__ppc32__sysv__macho__gas.S: Fix build failure on PPC Darwin

  darwin.compile.asm bin.v2/libs/context/build/darwin-4.5.3/release/link-static/threading-multi/asm/make_ppc32_sysv_macho_gas.o
  libs/context/src/asm/make_ppc32_sysv_macho_gas.S:85:Parameter syntax error (parameter 3)

(pho)

patches/patch-glib_gmain.c: Imported patch from the upstream Bugzilla

  Bug 728123 - glib2 @2.40.0 issues a "Got weird mach timebase info" error (Macports, PPC)
  https://bugzilla.gnome.org/show_bug.cgi?id=728123

Tested on powerpc-apple-darwin9.

(pho)

Check for aligned memory functions with cmake

Not all platforms have posix_memalign(3) so we need to check if it
exists. This fixes build failure on Darwin 9. See:
https://www.gnu.org/software/gnulib/manual/html_node/posix_005fmemalign.html

(pho)

Add AC_SYS_LARGEFILE to files/configure.ac

Given that libarchive is built with large file support, pkg_install
needs it too. Otherwise libarchive and pkg_install may see different
definitions of types such as struct stat, resulting in a runtime
failure on some platforms (especially Darwin 9):

  % bmake package
  => Creating binary package /usr/pkgsrc/pkgtools/pkg_install/work/.packages/pkg_install-20141227.tgz
  pkg_create: cannot write to archive: tar format cannot archive this (type=00)

The reason why this was unnoticed until now is that libarchive's
"configure" has just been regenerated with Autoconf 2.69. Prior to
2.69, AC_SYS_LARGEFILE did nothing significant on Darwin so there was
no actual inconsistency between libarchive and pkg_install, which was
just coincidental.

(pho)

Fix linkage failure of libmatroska due to missing -lebml flag.
This seems to be an actual issue only on non-ELF platforms.

Pull request sent and merged to the upstream:
https://github.com/Matroska-Org/libmatroska/pull/5

(pho)

Add 'c' to USE_LANGUAGES

Otherwise the configure script fails with:
  PKGSRC-WARNING: Something is trying to run the c compiler,
  PKGSRC-WARNING: but it is not added to USE_LANGUAGES in the package Makefile.

The package still don't build because of an upstream problem in Makefile.am, but it is a separate issue.

(pho)

PR 49591: Make launchd integration a package option, disabled by default for now.

launchd integration currently requires manual steps as described in MESSAGE.launchd. We may want to make it default once we have a framework for automatic launchd support.

(pho)

PR 49591: Add MESSAGE.launchd to let Darwin users know about the launchd agent configuration file.

(pho)

patches/patch-Makefile.in: Add a note that the patch has been sent to the upstream and will hopefully be merged soon.

(pho)

Forgot to update distinfo

(pho)

PR pkg/48740 - Fix build issues on Darwin < 9 and possibly other platforms

patches/patch-gcc_common.opt had a hunk that makes -fstack-protector enabled by default (without any comments) but it causes a bootstrapping problem on platforms whose libc don't provide functions for ssp.

(pho)

PR pkg/48740 - Fix build issues on Darwin

Apply a patch by Sevan:
  1. gcc needs to be built with dwarf2 if Darwin < 9
  2. if you're building on a 32bit PowerPC Darwin < 9, disable multilib

(pho)

Fix compilation issues on glibc-based platforms

(pho)

Let application restart work on MacOS X < 10.6

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.

(pho)

Fix PLIST for the case when graphics/cairo is built with quartz backend enabled

(pho)

Resurrect Quartz backend as package option "quartz" which is disabled by default

(pho)

PR pkg/48840: Remove most patches that I have recently added

The preprocessor macro XP_MACOSX is misused everywhere. They tend to
say "#if defined(XP_MACOSX)" to actually mean
"#if defined(MOZ_WIDGET_COCOA)". It's okay to equate XP_MACOSX with
XP_DARWIN but equating it with MOZ_WIDGET_COCOA is just wrong. As a
result, cairo-gtk2 build on Darwin is completely broken and needs
heavy patching. Ideally they should be fixed individually but that
will be an extremely hard work, so don't define XP_MACOSX for now.

(pho)

PR pkg/48840: Don't assume cocoa toolkit just because OS_ARCH is Darwin

(pho)

PR pkg/48840: Don't assume cocoa toolkit just because OS_ARCH is Darwin

(pho)

PR pkg/48840: Don't assume cocoa toolkit just because OS_ARCH is Darwin

(pho)

PR pkg/48840: Don't assume cocoa toolkit just because OS_ARCH is Darwin

(pho)

PR pkg/48840: Don't assume cocoa toolkit just because OS_ARCH is Darwin

(pho)

PR pkg/48840: OS_TEST can never be 'powerpc'

(pho)

PR pkg/48840: Set the MacOS X version requirement appropriately

Otherwise ${WRKSRC}/media/libcubeb/src/cubeb_audiounit.c can not be
built on MacOS X < 10.6

(pho)

PR pkg/48840: Fix configuration issues on Darwin

* On Darwin the profiler only supports x86 and x86_64.

* Cocoa gamepad backend can only be used if the toolkit is cocoa too.

(pho)

PR pkg/48840: Do not reject GCC on Darwin

It's true Clang is required if we use the cocoa toolkit, but we don't
do that anyway. GCC is perfectly working as long as we use cairo-gtk2.

(pho)

PR/48840: Fix PLIST on Cygwin and Darwin

libmozglue is built and installed as a shared library on these platforms.

(pho)

PR pkg/48840: Fix PLIST on Cygwin and Darwin

libmozglue is built and installed as a shared library on these platforms.

(pho)

Revbump after cairo update

(pho)

Correct PLIST for Darwin

Extra modules for this platform:
  - module-bonjour-publish
  - module-coreaudio-detect
  - module-coreaudio-device

(pho)

Don't use buggy CoreText in MacOS X 10.5

CTLineCreateWithAttributedString() seemingly fails when trying to use a
font which isn't installed into the system standard path.

(pho)

Darwin: cairomm-quartz is no longer installed because cairo-quartz is now disabled.

(pho)

Darwin: pangocoretext.h is no longer installed because cairo-quartz is now disabled.

(pho)

Disable Quartz backend on Darwin

Quartz backend interacts badly with our library stack. The most notable
issue is that when quartz-font is enabled, cairo will never use fontconfig
but instead uses CoreGraphics API to find fonts in system-default font
paths; as a result, any fonts installed with pkgsrc will never be found.
OTOH fontconfig by default searches for fonts in MacOS X system-default
paths too so sticking with it will not cause a problem.

(pho)

Correct wrong install_name for Darwin.

Makefile had a SUBST for this but it wasn't working.

(pho)

Fix issues on Darwin

Makefile:
  See ${WRKSRC}/libgcc/config/t-slibgcc-darwin: It uses strip(1) to
  create a stub library, not just to remove symbols, so we must not
  let strip(1) be a no-op regardless of ${INSTALL_UNSTRIPPED} or the
  build fails for missing files.

patches/patch-libgcc_config_t-slibgcc-darwin:
  If we don't install libgcc_s.10.[45].dylib, our gcc links binaries
  with *both* /usr/lib/libgcc_s.1.dylib and
  ${GCC_PREFIX}/lib/libgcc_s.1.dylib, which is certainly a bad thing.

patches/patch-libjava_Makefile.in:
  Tell libtool the fact that libjvm.so is a module to be opened with
  dlopen(3). This is actually needed on Mach-O systems like Darwin.

(pho)

New package option: gcc-objc++

(pho)

Fix build errors on Darwin

patches/patch-Graphite.cmake (CREATE_LIBTOOL_FILE):
  Fix incorrect library_names

patches/patch-src_CMakeLists.txt:
  Don't pass -nodefaultlibs to compiler or the build fails for missing
  symbols on PowerPC and possibly other platforms.

(pho)

Makefile: mpd requires gcc>=4.6 (see src/Compiler.h)

Makefile: Enable MacOS X audio output on Darwin

patches/patch-src_output_HttpdOutputPlugin.cxx:
  Fix compilation error on Mach-O systems (or at least on Darwin 9)

patches/patch-src_system_ByteOrder.hxx:
  Fix compilation error on Darwin/ppc

(pho)

Add a comment to patches/patch-ac

(pho)

PR pkg/48740 - Fix problems on Darwin

Makefile:
  See ${WRKSRC}/libgcc/config/t-slibgcc-darwin: It uses strip(1) to
  create a stub library, not just to remove symbols, so we must not
  let strip(1) be a no-op regardless of ${INSTALL_UNSTRIPPED} or the
  build fails for missing files.

patches/patch-ac:
  Remove the whitespace between $(LINKER_RPATH_FLAG) and the path.
  Otherwise the flag may be misinterpreted by linker (e.g. Apple's ld)

(pho)

PR pkg/48740 - Fix problems on Darwin

Makefile:
  See ${WRKSRC}/libgcc/config/t-slibgcc-darwin: It uses strip(1) to
  create a stub library, not just to remove symbols, so we must not
  let strip(1) be a no-op regardless of ${INSTALL_UNSTRIPPED} or the
  build fails for missing files.

patches/patch-ac:
  Remove the whitespace between $(LINKER_RPATH_FLAG) and the path.
  Otherwise the flag may be misinterpreted by linker (e.g. Apple's ld)

patches/patch-libgcc_config_t-slibgcc-darwin:
  If we don't install libgcc_s.10.[45].dylib, our gcc links binaries
  with *both* /usr/lib/libgcc_s.1.dylib and
  ${GCC_PREFIX}/lib/libgcc_s.1.dylib, which is certainly a bad thing.

(pho)

Fix build error on Darwin

Do not override XML_CATALOG_FILES on Darwin. That will only make
xmllint try to find a wrong catalog.

(pho)

Fix build error on platforms lacking AI_NUMERICSERV.

Not only Win32 lacks AI_NUMERICSERV. Some version of Darwin (at least Darwin 9) lacks it too.

(pho)

Fix build error on Darwin and possibly other platforms with DTrace capability

On platforms where DTrace is available, we need to invoke dtrace(1)
with the original PATH. Otherwise it gets confused in the presence
of our cc wrapper because it tries to invoke the system-default gcc
with argv[0] set to "gcc", not the absolute path to gcc.

(pho)

Fix build failure at least on Darwin:

atomic_ops_stack.c refers to AO_pause defined in atomic_ops.c so
either removing -no-undefined or declaring the dependency is needed.

(pho)

Fix build failure on platforms where O_CLOEXEC is not available (e.g. MacOS X < 10.7)

(pho)

GCC >= 4.4 is not required for architectures without ssse3.

(pho)

Fix build errors on GCC < 4.2

(pho)

Darwin: Fix an issue that gcc producing binaries linked with a wrong libgcc_s

If we don't install libgcc_s.10.[45].dylib, our gcc links binaries
with *both* /usr/lib/libgcc_s.1.dylib and
${GCC_PREFIX}/lib/libgcc_s.1.dylib, which is certainly a bad thing.

The problem was already reported to the upstream but it caught
seemingly no attention:
http://gcc.gnu.org/ml/gcc-help/2010-07/msg00164.html

(pho)

Fix build failure on Darwin

See ${WRKSRC}/libgcc/config/t-slibgcc-darwin: It uses strip(1) to
create a stub library, not just to remove symbols, so we must not
let strip(1) be a no-op regardless of ${INSTALL_UNSTRIPPED} or the
build fails for missing files.

(pho)

Remove the whitespace between $(LINKER_RPATH_FLAG) and the path. Otherwise the flag may be misinterpreted by linker (e.g. Apple's ld)

(pho)

Makefile should state that arp-scan depends on libpcap>=0.8 rather than implicitly depending on builtin libpcap.

(pho)

Fix breakage on platforms including Linux where `libtool --mode=link' does not automatically hard-code library run-time paths into executables.

(pho)

Fix build on Darwin 9.

(pho)

Record cocoa and quartz modules on Darwin in PLIST.

(pho)

Enable XFree86-DGA mouse and keyboard inputs. Bump revision.

The configure script determines the availability of libXxf86dga only by the existence of X11/extensions/xf86dga.h. This leads to a linkage error on platforms (e.g. Darwin) where the header in question can be found in the system default path but the corresponding library is installed elsewhere. The problem goes away if we had the library buildlinked, and I see no reason for not enabling DGA input anyway.

(pho)

Fix build on Darwin 9 and possibly some other platforms.

(pho)

Fix build on Darwin.

(pho)

Add ppc32 to Darwin targets

(pho)

Fix build of MesaLib on PowerPC platforms without GCC >= 4.1 (like MacOS X 10.5).

(pho)