some existing COMPILER lines with arch restrictions etc. In the usual
case this is now using "COMPILER = base-clang ports-gcc base-gcc" on
ports with c++ libraries in WANTLIB.
This is basically intended to be a noop on architectures using clang
as the system compiler, but help with other architectures where we
currently have many ports knocked out due to building with an unsuitable
compiler -
- some ports require c++11/newer so the GCC version in base that is used
on these archirtectures is too old.
- some ports have conflicts where an executable is built with one compiler
(e.g. gcc from base) but a library dependency is built with a different
one (e.g. gcc from ports), resulted in mixing incompatible libraries in the
same address space.
devel/gmp is intentionally skipped as it's on the path to building gcc -
the c++ library there is unused in ports (and not built by default upstream)
so intending to disable building gmpcxx in a future commit.
since SHARED_ONLY support was removed across the ports tree the perl module
no longer adds it, so it must be done manually for any perl ports that
provide perl shared-library modules (i.e. libdata/perl5/site_perl/$ARCH/*.so)
and you must not remove them from WANTLIB even if they show as "Extra".
Qt5 started to use libproxy and this exposed a crashing bug on OpenBSD
when using Qt5 applications on Gnome 3.
Here's a sample backtrace:
https://gist.github.com/mulander/c03997ae7e3fe4e30af0d4f2ce2965f0
The issue is caused by an unguarded dereference of ign_ip.
Other parts of the code properly expect that sockaddr_from_string
might return null and guard against it.
Adding a proper guard prevents a segfault both in OpenBSD
www/otter-browser and devel/zeal.
Issue reported upstream in:
https://github.com/libproxy/libproxy/issues/24
OK zhuk@ aja@
cmake.port.mk sets LIBfoo_VERSION for cmake to use as appropriate,
but this only works when the library name matches between SHARED_LIBS
and the cmake infrastructure - in this case there's a mismatch with
"proxy" vs "libproxy".
This used to be handled in this port by patching cmake files but
that's awkward to maintain so no surprise it accidentally got lost
in the last update; replace it by setting appropriate CONFIGURE_ENV
and MAKE_ENV in the port Makefile instead which is more maintainable.
Build problem with dependent ports reported by nigel@.
Re-enable the mozilla FLAVOR now that we have mozjs185.
Add bootstrap to PSEUDO_FLAVOR to prevent the dep loop with WebKit.
Move from if PSEUDO_FLAVOR... to BUILD_PACKAGES.
Fix DESCR-*
because I didn't sync PLIST-webkit (missed because it's only built as
a non-default pseudopackage); fix this by adding VERSION to SUBST_VARS
and syncing PLISTs, which also reduces the risk of problems in the future.
processing.
While there, remove unnecessary patches (some fixed upstream, some workarounds
for header problems which have since been cleaned up, and change the "Build the
pacrunner into libproxy" patch into -DBIPR:BOOL=OFF in CONFIGURE_ARGS instead).
ok ajacoutot@
