Provides a minimal R and C++ API for parsing well-known binary and
well-known text representation of geometries to and from R-native
formats. Well-known binary is compact and fast to parse; well-known
text is human-readable and is useful for writing tests. These formats
are only useful in R if the information they contain can be accessed
in R, for which high-performance functions are provided here.
WWW: https://cran.r-project.org/web/packages/wk/
ECHO is builtin variable and is cleared when make(1) is invoked
in silent mode, i.e. as ``make -s'', thus making statements that
use it do nothing. Depending on the context, replace it with
either ${ECHO_CMD} or ${ECHO_MSG} (in one case), as appropriate.
PR: 256185
Submitted by: Franco Fichtner
With the release of GCC 8.5 the GCC 8 release series has reached
end of life.
This also means the end of weekly snapshots. Remove lang/gcc8-devel
which has been tracking those and redirect to lang/gcc8 and that
final release instead.
Cherry-pick c0c4b55 from pfsense/FreeBSD-ports:
Add host stack OS endpoint support for netmap module.
Cherry-pick 52b6dea from pfsense/FreeBSD-ports:
Support host stack interfaces with netmap and NETMAP_API versions 13 and 14.
Cherry-pick 6914d3a from pfsense/FreeBSD-ports:
Backport NS_MOREFRAG bug fix from netmap upstream demo app code.
Approved by: zi (maintainer)
Sponsored by: Rubicon Communications, LLC ("Netgate")
Use ld.bfd:
ld: error: can't create dynamic relocation R_PPC_ADDR16_LO against symbol: caml_last_return_address in readonly segment; recompile object files with -fPIC or pass '-Wl,-z,notext' to allow text relocations in the output
Python now requires libffi from ports and does not build with LIBFFI
disabled, so remove the option.
PR: 256141
Reported by: majo-bugs.freebsd.org@cerny.sk
Reviewed by: koobs (python)
Approved by: koobs (python)
MFH: 2020Q2 (bugfix)
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
