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
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
- Cleanup seemingly unused {BUILD,LIB}_DEPENDS, adjust USES
- Do not require specific (85) version of Tcl/Tk
- Convert pkg-message to UCL format, sort pkg-plist
2019-05-08 cad/brlcad: Broken for more than 6 months
2019-05-12 misc/gnuit: Upstream stale for 10 years, no users it appears
2019-05-12 print/py-reportlab1: consider using latest upstream version in print/py-reportlab
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: antoine
Change x11/xorgproto to become a build time dependency when added to
USE_XORG. Change the dependency to be on the port, rather than a file the
port installs.
Fix fallout.
Bump portrevision on depending ports.
PR: 230909
Reviewed by: eadler
Approved by: portmgr (antoine)
Obtained from: https://github.com/FreeBSDDesktop/freebsd-ports/tree/feature/xorgproto
exp-run: antoine
Differential Revision: https://reviews.freebsd.org/D16906
Upstream used to distribute protocol headers as separate packages, but has
decided to merge those to a common package, named xorgproto. This update
tracks that change.
* Add a new port, x11/xorgproto, with are protocol headers for xorg.
* Hook the new protocol port to the build and to infrastructure in
bsd.xorg.mk.
* Update all ports with a dependency on any of the old *proto packages to
instead depend on xorgproto. Bump portrevision.
* Delete the old *proto packages, update MOVED.
PR: 230023
Submitted by: zeising
Approved by: portmgr (antoine)
exp-run by: antoine
already had USES=pathfix, although it did nothing. For those ports, I
either removed it as they were handling the pkgconfig files differently
or I removed patches and substitutions that accomplished the same thing
as pathfix.
Differential Revision: https://reviews.freebsd.org/D850
Reviewed by: antoine, bapt, tijl
Approved by: portmgr (bapt)
a zeising, kwm production, with help from dumbbell, bdrewery:
NEW XORG ON FREEBSD 9-STABLE AND 10-STABLE
This update switches over to use the new xorg stack by default on FreeBSD 9
and 10 stable, on osversions where vt(9) is available.
It is still possible to use the old stack by specifying WITHOUT_NEW_XORG in
/etc/make.conf .
FreeBSD 8-STABLE and released versions of FreeBSD still use
the old version.
A package repository with binary packages for new xorg will
be available soon.
This patch also contains updates of libxcb and related ports, pixman, as well
as some drivers and utilities.
Bump portrevisions for xf86-* ports, as well as virtualbox-ose-additions due
to xserver version change.
Apart from these updates, the way shared libraries are handled has been
changed for all xorg ports, as well as libxml2 and freetype, which means
ltverhack is gone and as a consequence shared libraries have been bumped.
The plan is that this change will make library bumps less likely in the
future.
All affected ports have had their portrevisions bumped as a consequence of
this.
Fix some issues where WITH_NEW_XORG weren't detected properly on CURRENT.
Update instructions, hardware support, and more notes can be found on
https://wiki.freebsd.org/Graphics
Thanks to: all testers, bdrewery and the FreeBSD x11@ team
exp-run by: bdrewery [1]
PR: ports/187602 [1]
Approved by: portmgr (bdrewery), core (jhb)
With contributions from Schaich Alonso <alonsoschaich@fastmail.fm>,
including stage support for devel/cmake-gui.
This update took much longer than expected due to CMake changing the
arguments to an internal macro that ended up being used by some ports:
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=9ce60ff5
I have also started a discussion about this on CMake's development list:
http://article.gmane.org/gmane.comp.programming.tools.cmake.devel/8464
It required adjusting the affected ports, and these changes have approved by
portmgr (bdrewery).
PR: ports/182981
Approved by: portmgr (bdrewery)
an zeising, kwm, miwi, bapt, eadler production:
Xorg 7.7
Starring:
xserver 1.12.4 (new xorg only)
Mesa 8.0.4, including libGL, libGLU and dri (new xorg only)
libX11 1.5.0
libxcb 1.9
libdrm 2.4.42 (new xorg only)
freeglut 2.8.1
Also starring:
Updates to drivers and other libraries and utilities
Additional notes:
Change pkgconf to be a build dependency.
Add a new USE_XORG, xcb, to depend on libxcb and update all ports to use
this.
Trim makefile headers.
Take maintanership of x11/xcb-proto, ok'd by ashish.
If you are running WITH_NEW_XORG=, you need to rebuild all installed
drivers, see UPDATING for more information.
Various fixes to make ports compile.
PR: ports/177942
Exp-run by: miwi
Approved by: portmgr (miwi)
Thanks to all who helped testing!
If a port used other USE_GNOME items it was untouched.
The ports that used other USES were fixed by hand.
PR: ports/177081
Reviewed by: bapt
Approved by: portmgr (miwi)
It brings bison as a build dependency in case it is set the following way:
USES= bison or USES= bison:build
it brings bison as a run dependency in case it is set the following way:
USES= bison:run
it brings bison both as a run and build dependency in case it the set the following way:
USES= bison:both
While here trim some headers
Convert some USE_GNOME= gnomehack to USES= pathfix
In file included from /usr/local/include/tk8.5/tkInt.h:974,
from /ports/cad/brlcad/work/brlcad-7.22.0/src/other/togl/src/togl.c:27:
/usr/local/include/tk8.5/tkIntDecls.h:672:
error: expected declaration specifiers or '...' before '(' token
/usr/local/include/tk8.5/tkIntDecls.h:672:
error: conflicting types for 'XClipBox'
/usr/local/include/X11/Xutil.h:381:
error: previous declaration of 'XClipBox' was here
Reported by: pointyhat
