- Update to 1.898c66039aa7
Port details
devel/cppcheck2.21.1
Tool for static C/C++ code analysis
- Maintainer
- amdmi3@FreeBSD.org
- Packages
- cppcheck 2.21.1
- Upstream
- Higher version available: 2.22.0
- CPE
cppchecksolutions:cppcheckfrom the port- WWW
- https://cppcheck.sourceforge.io/
- Links
- cgit · VuXML
Unaddressed (0) · The CVE record lists this version as affected, no VuXML entry names the CVE
None. There is no CVE without a VuXML entry for this version.
VuXML only (0) · listed, port not fixed yet
None.
pkg audit reports nothing for this version.Fixed (0)
No VuXML entries for this package.
Commits (141)
Bump PORTREVISION for ports depending on the canonical version of GCC as defined in Mk/bsd.default-versions.mk which has moved from GCC 8.3 to GCC 9.1 under most circumstances now after revision 507371. This includes ports - with USE_GCC=yes or USE_GCC=any, - with USES=fortran, - using Mk/bsd.octave.mk which in turn features USES=fortran, and - with USES=compiler specifying openmp, nestedfct, c11, c++0x, c++11-lang, c++11-lib, c++14-lang, c++17-lang, or gcc-c++11-lib plus, everything INDEX-11 shows with a dependency on lang/gcc9 now. PR: 238330ea8c8ec7da
- Update to 1.88cb553ee31b
- Update to 1.87f051a97d33
Fix Qt5 symbol version scripts to put the catch-all clause first. When a symbol matches multiple clauses the last one takes precedence. If the catch-all is last it captures everything. In the case of Qt5 libraries this caused all symbols to have a Qt_5 label while some should have Qt_5_PRIVATE_API. This only affects lld because GNU ld always gives the catch-all lowest priority. Older versions of Qt5Webengine exported some memory allocation symbols from the bundled Chromium. Version 5.9 stopped exporting these [1] but the symbols were kept as weak wrappers for the standard allocation functions to maintain binary compatibility. [2][3] The problem is that the call to the standard function in these weak wrappers is only resolved to the standard function if there's a call to this standard function in other parts of Qt5Webengine, because only then is there a non-weak symbol that takes precedence over the weak one. If there's no such non-weak symbol the call in the weak wrapper resolves to the weak wrapper itself creating an infinite call loop that overflows the stack and causes a crash. Some of the allocation functions are variants of C++ new and delete and it probably depends on the compiler whether these variants are used in other parts of Qt5Webengine. Remove the weak wrappers (make them Linux specific). This isn't binary compatible but we are already breaking that with the changes to the symbol versions. [1] https://github.com/qt/qtwebengine/commit/5c2cbfccf9aafb547b0b30914c4056abd25942a4 [2] https://github.com/qt/qtwebengine/commit/2ed5054e3a800fa97c2c9e920ba1e6ea4b6ef2a5 [3] https://github.com/qt/qtwebengine/commit/009f5ebb4bd6e50188671e0815a5dae6afe39db5 Bump all ports that depend on Qt5. PR: 234070 Exp-run by: antoine Approved by: kde (adridg)1bf487d3e7
Change cmake default behaviour to outsource. Ports that build out of source now simply can use "USES=cmake" instead of "USES=cmake:outsource". Ports that fail to build out of source now need to specify "USES=cmake:insource". I tried to only set insource where explictely needed. PR: 232038 Exp-run by: antoine707c6bf295
- Update to 1.863b727993c5
Bump PORTREVISION for ports depending on the canonical version of GCC defined via Mk/bsd.default-versions.mk which has moved from GCC 7.4 t GCC 8.2 under most circumstances. This includes ports - with USE_GCC=yes or USE_GCC=any, - with USES=fortran, - using Mk/bsd.octave.mk which in turn features USES=fortran, and - with USES=compiler specifying openmp, nestedfct, c11, c++0x, c++11-lang, c++11-lib, c++14-lang, c++17-lang, or gcc-c++11-lib plus, as a double check, everything INDEX-11 showed depending on lang/gcc7. PR: 231590a9f015d155
- Update to 1.856e87ea070a
Bump PORTREVISION for ports depending on the canonical version of GCC in the ports tree (via Mk/bsd.default-versions.mk and lang/gcc) which has now moved from GCC 6 to GCC 7 by default. This includes ports - featuring USE_GCC=yes or USE_GCC=any, - featuring USES=fortran, - using Mk/bsd.octave.mk which in turn features USES=fortran, and those - with USES=compiler specifying one of openmp, nestedfct, c11, c++0x, c++11-lib, c++11-lang, c++14-lang, c++17-lang, or gcc-c++11-lib. PR: 22254209f9633cb6
Replace bsd.qt.mk by Uses/qt.mk and Uses/qt-dist.mk From now on, ports that depend on Qt4 will have to set USES= qt:4 USE_QT= foo bar ports depending on Qt5 will use USES= qt:5 USE_QT= foo bar PR: 229225 Exp-run by: antoine Reviewed by: mat Approved by: portmgr (antoine) Differential Revision: →https://reviews.freebsd.org/D15540b1a1d38bf9
- Regenerate patches, as patching fails in some cases (could not reproduce though) PR: 229005 Reported by: rozhuk.im@gmail.com5a7e5c39cf
- Update to 1.84edfd298a5c
- Update to 1.8330f8d6e2ce
Fix build when Qt libs are present, but qmake is not Reported by: Walter Schwarzenfeld <w.schwarzenfeld@utanet.at>63797b032b
- Update to 1.82a20ba2e041
- Remove python version limitationb98990ca5f
Re-try ports affected by bug 193528 on powerpc* after r44959003fec4df02
Convert Python ports to FLAVORS.
Ports using USE_PYTHON=distutils are now flavored. They will
automatically get flavors (py27, py34, py35, py36) depending on what
versions they support.
There is also a USE_PYTHON=flavors for ports that do not use distutils
but need FLAVORS to be set. A USE_PYTHON=noflavors can be set if
using distutils but flavors are not wanted.
A new USE_PYTHON=optsuffix that will add PYTHON_PKGNAMESUFFIX has been
added to cope with Python ports that did not have the Python
PKGNAMEPREFIX but are flavored.
USES=python now also exports a PY_FLAVOR variable that contains the
current python flavor. It can be used in dependency lines when the
port itself is not python flavored. For example, deskutils/calibre.
By default, all the flavors are generated. To only generate flavors
for the versions in PYTHON2_DEFAULT and PYTHON3_DEFAULT, define
BUILD_DEFAULT_PYTHON_FLAVORS in your make.conf.
In all the ports with Python dependencies, the *_DEPENDS entries MUST
end with the flavor so that the framework knows which to build/use.
This is done by appending '@${PY_FLAVOR}' after the origin (or
@${FLAVOR} if in a Python module with Python flavors, as the content
will be the same). For example:
RUN_DEPENDS= ${PYTHON_PKGNAMEPREFIX}six>0:devel/py-six@${PY_FLAVOR}
PR: 223071
Reviewed by: portmgr, python
Sponsored by: Absolight
Differential Revision: https://reviews.freebsd.org/D12464551be3c723Fix the context of some patches so that they apply with stricter patch(1) PR: 223545 With hat: portmgr13ca35d735
- Update to 1.81202031d76c
Bump PORTREVISION for ports depending on the canonical version of GCC (via Mk/bsd.default-versions.mk and lang/gcc) which has moved from GCC 5.4 to GCC 6.4 under most circumstances. This includes ports - with USE_GCC=yes or USE_GCC=any, - with USES=fortran, - using Mk/bsd.octave.mk which in turn features USES=fortran, and - with USES=compiler specifying openmp, nestedfct, c++11-lib, c++11-lang, c++14-lang, c++0x, c11, or gcc-c++11-lib. PR: 219275e59c88cece
- Update to 1.8006a52e8726
- Move cppcheck gui into separate port, devel/cppcheck-guie4a2f3ae51
- Update to 1.79 - Fix segfault due to conflict between bundled and system tinyxml [1] - Switch to cmake build, simplifying the port - Enable GUI PR: 217881 [1], 218876 [1]c9bbe54ef5
Mark some ports failing on power64. In cases where the error message was a stub, provide a real one. While here, pet portlint. Approved by: portmgr (tier-2 blanket) Reported by: swillsfa74598719
- Add missing python dependency (both build- and runtime) - Fix shebang in python script Reported by: Walter Schwarzenfeld <w.schwarzenfeld@utanet.at>0a4ba19cd2
- Update to 1.782b3838ff61
Bump PORTREVISIONs for ports depending on the canonical version of GCC and lang/gcc which have moved from GCC 4.9.4 to GCC 5.4 (at least under some circumstances such as versions of FreeBSD or platforms). This includes ports - with USE_GCC=yes or USE_GCC=any, - with USES=fortran, - using using Mk/bsd.octave.mk which in turn has USES=fortran, and - with USES=compiler specifying openmp, nestedfct, c++11-lib, c++14-lang, c++11-lang, c++0x, c11, or gcc-c++11-lib. PR: 21670704d6f52202
- Update to 1.77a50dbd361d
- Update to 1.76.1138a7030c2
- Update to 1.76b75a7e79ac
- Update to 1.75889d0c7065
- Update to 1.740b009efd6f
- Update to 1.7336deb3c072
Remove ${PORTSDIR}/ from dependencies, categories d, e, f, and g.
With hat: portmgr
Sponsored by: Absolight4e1b79a0a6- Update to 1.721c79ab0d9b
Convert LICENSE= "GPLxx # or later" to "GPLxx+" Approved by: portmgr blanketb9398223bd
- Update to 1.71 - Take maintainership in compliance with porter's handbook §5.5 (3 consecutive maintainer timeouts) PR: 204917 Submitted by: amdmi3 Approved by: maintainer timeout (bf, 2 weeks)1b5b1326f5
- Update to 1.70 - Use options helpers - Use test framework PR: 204325 Submitted by: amdmi3 Approved by: maintainer timeout (bf, 2 weeks)b0d65ac40f
- Update to 1.69 - Add LICENSE_FILE PR: 202392 Submitted by: amdmi3 Approved by: maintainer timeout (bf, 3 weeks)7b18a2d4bb
- Update to 2.2.0 - Simplify Makefile - Bump PORTREVISION for textproc/tinyxml2 shlib change Changes: https://github.com/leethomason/tinyxml2/commits/master PR: 196884 Submitted by: sunpoet (myself) Approved by: maintainer (timeout, 1 month)9977149e7d
- Convert ports of devel/ to USES=python Approved by: portmgr (implicit)89e07f4a18
Remove a few remaining NOPORTDATA With hat: portmgr639cb537b5
- Convert USE_BZIP2 to USES Approved by: portmgr blanket3b2f459f19
Correct the plist for the case when the manpage isn't built, and use a more specific option name PR: 186588, 186795 Submitted by: amdmi3, K. Zhengda20974526
Update textproc/tinyxml2 to 20140124 and devel/cppcheck to 1.63; use staging for bothc9266fcc1e
Python cleanup: - USE_PYTHON* = 2.X -> USE_PYTHON* = 2 - USE_PYTHON* = 2.X+ -> USE_PYTHON* = yes Reviewed by: python (mva, rm) Approved by: portmgr-lurkers (mat)50f8eaece1
Update textproc/tinyxml2 to 20131105, and devel/cppcheck to 1.6218b0fd8d39
Add NO_STAGE all over the place in preparation for the staging support (cat: devel part 1)857aec5d6b