Details:
- The low number of i386 leads to register exhaustion when compiling
with LTO. Due to the decreasing popularity of 32 bit i386 machines
which require hyper-optimised ffmpeg builds, the option is excluded
from the builds for now.
PR: 257124
MFH: 2021Q3
efe6165a6e14 (downstream) forgot to chase patch split into n4.4 version
===> Patching for ffmpeg-4.4_1,1
===> Applying distribution patches for ffmpeg-4.4_1,1
4 out of 4 hunks failed--saving rejects to configure.rej
1 out of 1 hunks failed--saving rejects to libavcodec/Makefile.rej
1 out of 1 hunks failed--saving rejects to libavcodec/allcodecs.c.rej
===> FAILED Applying distribution patch 0001-lavc-svt_hevc-add-libsvt-hevc-encoder-wrapper.patch with -p1
*** Error code 1
but v1.5.1 (upstream) forgot to update/split docs patch
===> Patching for ffmpeg-4.4_1,1
===> Applying distribution patches for ffmpeg-4.4_1,1
patch: **** malformed patch at line 177: @section libtheora
===> FAILED Applying distribution patch 0002-doc-Add-libsvt_hevc-encoder-docs.patch with -p1
*** Error code 1
libavfilter/vf_lensfun.c:229:63: error: too many arguments to function call, expected 5, have 7
inlink->h, LF_PF_U8, lensfun->reverse);
^~~~~~~~~~~~~~~~~~~~~~~~~~
/usr/local/include/lensfun/lensfun.h:3075:11: note: 'lf_modifier_create' declared here
LF_EXPORT lfModifier *lf_modifier_create (
^
libavfilter/vf_lensfun.c:231:119: error: too few arguments to function call, expected 5, have 3
lf_modifier_enable_vignetting_correction(lensfun->modifier, lensfun->aperture, lensfun->focus_distance);
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ^
/usr/local/include/lensfun/lensfun.h:3097:11: note: 'lf_modifier_enable_vignetting_correction' declared here
LF_EXPORT int lf_modifier_enable_vignetting_correction (
^
libavfilter/vf_lensfun.c:233:75: error: too few arguments to function call, expected 3, have 1
lf_modifier_enable_distortion_correction(lensfun->modifier);
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ^
/usr/local/include/lensfun/lensfun.h:3091:11: note: 'lf_modifier_enable_distortion_correction' declared here
LF_EXPORT int lf_modifier_enable_distortion_correction (lfModifier *modifier, const lfLens* lens, float focal);
^
libavfilter/vf_lensfun.c:234:100: error: too few arguments to function call, expected 4, have 2
lf_modifier_enable_projection_transform(lensfun->modifier, lensfun->target_geometry);
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ^
/usr/local/include/lensfun/lensfun.h:3101:11: note: 'lf_modifier_enable_projection_transform' declared here
LF_EXPORT cbool lf_modifier_enable_projection_transform (
^
/usr/local/include/lensfun/lensfun.h:115:15: note: expanded from macro 'cbool'
#define cbool int
^
libavfilter/vf_lensfun.c:238:68: error: too few arguments to function call, expected 3, have 1
lf_modifier_enable_tca_correction(lensfun->modifier);
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ^
/usr/local/include/lensfun/lensfun.h:3094:11: note: 'lf_modifier_enable_tca_correction' declared here
LF_EXPORT int lf_modifier_enable_tca_correction (lfModifier *modifier, const lfLens* lens, float focal);
^
PR: 255035
vec_xl function is already defined in altivec.h. Don't redefine it.
While here, remove the previous patch that is no longer needed with LLVM 11.
Since for LTO LLVM 9 is used, switch to GCC for LTO option.
Turns out that clang can build proper binaries when using LTO, if bfd is
used instead of lld.
LLVM from ports is necessary because LLVMgold.so is not present in base.
Approved by: tier 2 blanket
This is a major upgrade from 3.x to 4.x.
Changelog from versions 3.4.1--4.5.1 can be found here:
https://github.com/opencv/opencv/wiki/ChangeLog
Note: this has explicitely not been added as a new graphics/opencv4 port, but replaces the
previous graphics/opencv[3] port. Again, to improve maintainability by not giving ports
the option to pick the "wrong one" - this leads however to some abandoned ports being
broken.
The port has been greatly simplified:
* graphics/opencv-core which existed to enable ffmpeg to depend on opencv, and vice versa
has been removed. ffmpeg no longer can depend on opencv.
* graphics/py-opencv has been integrated into graphics/opencv, the default versions python
bindings will be built unless the PYTHON option is explicitely turned off.
* graphics/opencv-java has been integrated into graphics/opencv -- it is off by default,
but can be enabled by toggling the JAVA option -- there are no consumers in the tree,
so that option might go away in the future.
* All the previous options have been removed and replaced by a (hopefully) sane set of
dependencies that make the port and package most usable for the majority of consumers.
- Please let me know if you think there are better defaults (i.e. anything that is missing,
or something that should not be dependet on).
- If you think something should be added or removed, please open a bug report.
- If you think something should be added as an optional dependency, please open a
bug report (with a good reason [tm]).
The depending ports have been updated to work against opencv4, or marked broken.
* Ports broken:
- graphics/rubygem-objectdetect: OpenCV4 no longer ships opencv-1.0 API
- graphics/p5-Image-ObjectDetect: OpenCV4 no longer ships opencv-1.0 API
- graphics/gimp-gmic-plugin: OpenCV4 no longer ships opencv-1.0 API
* Backports:
- misc/visp: dfa7e4bd47
- multimedia/zart: 6ca1964690,
d3a2931b1a
* Others:
- misc/actiona: switch to pkgconfig 'opencv4'
- multimedia/libav: drop opencv support
- misc/darknet: already failed to build prior to the upgrade
- math/saga: remove patching added to work against opencv3
- switch to the more modern version of librsvg2 on architectures
supporting rust
- this will fix some graphical issues on these architectures
PR: 250276
Exp-run by: antoine
Submitted by: tobik
Differential Revision: https://reviews.freebsd.org/D18878
ridiculous need to bump PORTREVISION of depending ports, whenever a
dependency is updated, but here we still are...
Bump PORTREVISION for the 9 users of x265 now that it has been
upgraded from 3.2 to 3.4.
SVT patches no longer need to be applied in a specific order to enable
more than one SVT encoder.
PR: 248166
Submitted by: VVD <vvd@unislabs.com>
MFH: 2020Q3 (simplify future MFHs)
MMX was too specific while SSE included AVX family. VFP became default
due to -mfloat-abi=hard. NEON can be toggled via CPUTYPE. Instead use
one option to disable all assembly which is enough for debugging.
