librsvg drags in cairo, fontconfig, freetype, gdk-pixbuf, gettext, git,
glib gobject-introspection, harfbuzz, icu4c, intltool, jpeg, libcroco,
libffi, libpng, librsvg, libtiff, pango, pcre, pixman, and
shared-mime-info, and still manages not to be linked unless you build
with cocoa, which defaults to off.
Closes#6415.
Signed-off-by: ilovezfs <ilovezfs@icloud.com>
formerly headonly, but now has tagged releases
see Homebrew/homebrew-head-only#205, urbit/urbit#721
Closes#6273.
Signed-off-by: Baptiste Fontaine <b@ptistefontaine.fr>
See https://github.com/FFmpeg/FFmpeg/blob/n3.2/Changelog.
* openh264 1.6 support added (FFmpeg/FFmpeg@293676c); drop vendored
openh264 1.5.
* Deprecate --with-sdl in favor of --with-sdl2, and point --with-ffplay
to --with-sdl2 too. FFplay now uses sdl2 as its backend.
* Drop the AAC encoding caveats specific to the FFmpeg 3.0 release. It's
been out for the better part of a year and shouldn't be news
anymore. Users concerned with this caveat should have migrated already.
* Sort options and optional dependencies. They're a mess and I didn't
even know where to insert options and dependencies.
Without docbook-xsl and the corresponding XML_CATALOG_FILES in the
environment, xsltproc(1) attempts to load .xsl files, e.g.,
http://docbook.sourceforge.net/release/xsl/current/html/lists.xsl, from
the Internet, and when the build is parallelized, that is, multiple
xsltproc processes attempt to fetch the same .xsl file at the same time
and presumably write to the same location, a race condition is triggered
and all processes exit with status 5.
An alternative fix is ENV.deparallelize, but having to fetch .xsl files
on the go and thus preventing offline builds is probably something to be
frowned upon.
Closes#6402.
Signed-off-by: Tomasz Pajor <tomek@polishgeeks.com>
Need to insert the vendored include path into CFLAGS, or the compiler
won't be able to find those headers.
Closes#6401.
Signed-off-by: Tomasz Pajor <tomek@polishgeeks.com>
On Sierra, use new upstream dynamic-library-dirs field to avoid
ghc: panic! (the 'impossible' happened)
malformed mach-o: load commands size (x) > 32768
where x is some number larger than 32768.
Note that this fix requires a corresponding update to cabal-install and
that `cabal new-build` hasn't been updated to use the new field yet, so
will continue to fail in the same scenarios as it already does.
Also, bump the vendored gmp to 6.1.1 for all macOS versions, and stop
using nm-classic since llvm-nm -P is POSIX compliant now.
Closes#6358.
Signed-off-by: ilovezfs <ilovezfs@icloud.com>