Per discussion with bapt on helping pkg handle the changing of these
deps and avoiding impossible upgrade senarios.
PR: 246767
Reviewed by: manu, bapt
Approved by: x11
Differential Revision: https://reviews.freebsd.org/D30824
From [1]
* What is new in gsl-2.7:
* fixed doc bug for gsl_histogram_min_bin (lhcsky at 163.com)
* fixed bug #60335 (spmatrix test failure, J. Lamb)
* fixed bug #36577
* clarified documentation on interpolation accelerators (V. Krishnan)
* fixed bug #45521 (erroneous GSL_ERROR_NULL in ode-initval2, thanks to M. Sitte)
* fixed doc bug #59758
* fixed bug #58202 (rstat median for n=5)
* added support for native C complex number types in gsl_complex
when using a C11 compiler
* upgraded to autoconf 2.71, automake 1.16.3, libtool 2.4.6
* updated exponential fitting example for nonlinear least squares
* added banded LU decomposition and solver (gsl_linalg_LU_band)
* New functions added to the library:
- gsl_matrix_norm1
- gsl_spmatrix_norm1
- gsl_matrix_complex_conjtrans_memcpy
- gsl_linalg_QL: decomp, unpack
- gsl_linalg_complex_QR_* (thanks to Christian Krueger)
- gsl_vector_sum
- gsl_matrix_scale_rows
- gsl_matrix_scale_columns
- gsl_multilarge_linear_matrix_ptr
- gsl_multilarge_linear_rhs_ptr
- gsl_spmatrix_dense_add (renamed from gsl_spmatrix_add_to_dense)
- gsl_spmatrix_dense_sub
- gsl_linalg_cholesky_band: solvem, svxm, scale, scale_apply
- gsl_linalg_QR_UD: decomp, lssolve
- gsl_linalg_QR_UU: decomp, lssolve, QTvec
- gsl_linalg_QR_UZ: decomp
- gsl_multifit_linear_lcurvature
- gsl_spline2d_eval_extrap
* bug fix in checking vector lengths in gsl_vector_memcpy (dieggsy@pm.me)
* made gsl_sf_legendre_array_index() inline and documented
- gsl_sf_legendre_nlm()
[1] http://git.savannah.gnu.org/cgit/gsl.git/tree/NEWS
PR: 256423
Exp-run by: antoine
During an exp-run for llvm 12 (see bug 255570), it turned out that
cad/brlcad does not build with clang 12.0.0:
[ 99% 4379/4403] cd /wrkdirs/usr/ports/cad/brlcad/work/brlcad-7.30.2/db/nist && /wrkdirs/usr/ports/cad/brlcad/work/brlcad-7.30.2/bin/step-g -O /wrkdirs/usr/ports/cad/brlcad/work/brlcad-7.30.2/share/db/nist/NIST_MBE_PMI_11.g /wrkdirs/usr/ports/cad/brlcad/work/brlcad-7.30.2/db/nist/NIST_MBE_PMI_11.stp > /wrkdirs/usr/ports/cad/brlcad/work/brlcad-7.30.2/db/nist/NIST_MBE_PMI_11.log 2>&1
FAILED: share/db/nist/NIST_MBE_PMI_11.g
What happens is that the step-g intermediate program segfaults, because
it attempts to access a null pointer. Valgrind shows:
Reading Data from /wrkdirs/share/dim/ports/cad/brlcad/work/brlcad-7.30.2/db/nist/NIST_MBE_PMI_11.stp...
HEADER read:
==24919== Invalid read of size 4
==24919== at 0x1337BA10: EntList::firstNot(JoinType) (entlist.cc:39)
==24919== by 0x1337C93E: nextNot (complexSupport.h:185)
==24919== by 0x1337C93E: AndList::matchNonORs(EntNode*) (non-ors.cc:135)
==24919== by 0x1337B77C: ComplexList::matches(EntNode*) (complexlist.cc:176)
==24919== by 0x1337B36A: ComplexCollect::supports(EntNode*) const (collect.cc:140)
==24919== by 0x1335FA5A: STEPcomplex::Initialize(char const**, char const*) (STEPcomplex.cc:126)
==24919== by 0x1335F774: STEPcomplex::STEPcomplex(Registry*, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const**, int, char const*) (STEPcomplex.cc:33)
==24919== by 0x1331842E: STEPfile::CreateSubSuperInstance(std::__1::basic_istream<char, std::__1::char_traits<char> >&, int, ErrorDescriptor&) (STEPfile.cc:1048)
==24919== by 0x13315E15: STEPfile::CreateInstance(std::__1::basic_istream<char, std::__1::char_traits<char> >&, std::__1::basic_ostream<char, std::__1::char_traits<char> >&) (STEPfile.cc:833)
==24919== by 0x133158B1: STEPfile::ReadData1(std::__1::basic_istream<char, std::__1::char_traits<char> >&) (STEPfile.cc:502)
==24919== by 0x13319EA8: STEPfile::AppendFile(std::__1::basic_istream<char, std::__1::char_traits<char> >*, bool) (STEPfile.cc:1674)
==24919== by 0x1331C984: STEPfile::ReadExchangeFile(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, bool) (STEPfile.inline.cc:119)
==24919== by 0x3AFDCE: STEPWrapper::load(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >&) (STEPWrapper.cpp:1300)
==24919== Address 0x8 is not stack'd, malloc'd or (recently) free'd
==24919==
==24919==
==24919== Process terminating with default action of signal 11 (SIGSEGV): dumping core
==24919== Access not within mapped region at address 0x8
==24919== at 0x1337BA10: EntList::firstNot(JoinType) (entlist.cc:39)
==24919== by 0x1337C93E: nextNot (complexSupport.h:185)
==24919== by 0x1337C93E: AndList::matchNonORs(EntNode*) (non-ors.cc:135)
==24919== by 0x1337B77C: ComplexList::matches(EntNode*) (complexlist.cc:176)
==24919== by 0x1337B36A: ComplexCollect::supports(EntNode*) const (collect.cc:140)
==24919== by 0x1335FA5A: STEPcomplex::Initialize(char const**, char const*) (STEPcomplex.cc:126)
==24919== by 0x1335F774: STEPcomplex::STEPcomplex(Registry*, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const**, int, char const*) (STEPcomplex.cc:33)
==24919== by 0x1331842E: STEPfile::CreateSubSuperInstance(std::__1::basic_istream<char, std::__1::char_traits<char> >&, int, ErrorDescriptor&) (STEPfile.cc:1048)
==24919== by 0x13315E15: STEPfile::CreateInstance(std::__1::basic_istream<char, std::__1::char_traits<char> >&, std::__1::basic_ostream<char, std::__1::char_traits<char> >&) (STEPfile.cc:833)
==24919== by 0x133158B1: STEPfile::ReadData1(std::__1::basic_istream<char, std::__1::char_traits<char> >&) (STEPfile.cc:502)
==24919== by 0x13319EA8: STEPfile::AppendFile(std::__1::basic_istream<char, std::__1::char_traits<char> >*, bool) (STEPfile.cc:1674)
==24919== by 0x1331C984: STEPfile::ReadExchangeFile(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, bool) (STEPfile.inline.cc:119)
==24919== by 0x3AFDCE: STEPWrapper::load(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >&) (STEPWrapper.cpp:1300)
==24919== If you believe this happened as a result of a stack
==24919== overflow in your program's main thread (unlikely but
==24919== possible), you can try to increase the size of the
==24919== main thread stack using the --main-stacksize= flag.
==24919== The main thread stack size used in this run was 16777216.
To fix this, add null pointer checks to EntList::firstNot() and various
other EntList functions.
Approved by: erik@brlcad.org (maintainer)
PR: 256166
MFH: 2021Q2
The port had been makred broken due to build issed with fig2dev
version 3.2.7, which has been upgraded to 3.2.8a, allowing this
port to be built again.
USE_GCC=any has been equivalent to USE_GCC=yes in most cases (such
as i386 and amd64 since 12.x and depending on configuration 11.x,
most newer installations on other platforms, and 13.x across the
board).
Since commit 96c17633d9 Mk/bsd.gcc.mk is treating them as
different spellings of the same, so continue the deorbiting of the
USE_GCC=any form and simply replace it with USE_GCC=yes.
This should not make any functional difference at all.
Discussed with: mat, linimon, pkubaj
Since the previous update changed USES=python from 3.6+ to 3.7+, all
dependent ports must have USES=python:3.7+ as well, otherwise it breaks
the @py36 flavor.
PR: 255347
Reported by: sunpoet
For ports that already use the licenses framwork, merge the content of
RESTRICTED/NO_CDROM/LEGAL* entries into LICENSEs.
Approved by: rene
Differential Revision: https://reviews.freebsd.org/D30010
