- Use vm_pager_allocate() to allocate OBJT_PHYS objects. This ensures
that they're initialized properly.
- Don't assume that user wiring will succeed.
This had been a team effort, with multiple independent reports,
a wide variety of experiments, and patches written by kib@
and refined by markj@.
I'm bumping PORTREVISION and aligning the revision of both kmod and
application; it's possible the application bump isn't actually
needed but let's make sure they both get rebuilt with this
important (because of changed kernel assumptions) fix.
PR: 249326
Submitted by: kib, markj
Reported by: adridg, Rainer Hurling
Reviewed by: adridg
Approved by: koobs (vbox)
MFH: 2020Q3
I removed a bzero() call to reduce compiler warnings in the previous commit
(r544829). It turned out the next memcpy() call was also wrong. Just use
natural assignments here not to obfuscate the code.
Reported by: Martin Simmons (martin at lispworks dot com) (some time ago)
- Adapt and regenerate patches
- Reduce differences in patch-src_VBox_Devices_PC_vbox-cpuhotplug.dsl [1]
Patch based on one provided by Mario Lobo <lobo@bsd.com.br>.
Many thanks to people who provided ideas and suggetions in the
PR and review.
PR: 244212
Submitted by: Nikita Stepanov <nikitastepan0v@bk.ru>
Reviewed by: kevans [1]
Tested by: lwshu
Approved by: ports-secteam (joneum)
MFH: 2020Q3
Security: 1e7b316b-c6a8-11ea-a7d5-001999f8d30b
Differential Revision: https://reviews.freebsd.org/D25496
The runtime breakage that started occurring after the LLVM 7 -> 8 transition
has been diagnosed with help from cem@, and the attached patch fixes it. The
problem ended up being that tail-call optimization was being applied to this
function (which should probably be written in assembly instead) and moving
the tail-call to later on after some stack manipulations. The problem with
this is that this particular function uses alloca() to carefully craft a
stack that it's expecting to be used for the function it's calling at the
end.
The new patch fixes this using a technique that was committed later on in
upstream changeset 75061 to address a similar failure with GCC sanitizers
enabled. The FreeBSD-specific component of this patch is using the different
stack setup if __clang__ is defined as well.
The extra hunk in the Config patch has been added because the VirtualBox
build system cannot cope with LLVM version numbers in the way it's
expecting. Hardcode it to GCC 4.2 for FreeBSD, which is what the clang
__GNU* macros describe, to fix build breakage that happens with newer LLVM
as the build system decides our LLVM is an even older and more broken
version of GCC with a broken regparm.
PR: 236616, 244847
Approved by: koobs (mentor)
MFH: 2020Q2 (blanket: major runtime build fix)
This is a regression of something that was working in the past. Please
keep the _GCC_RUNTIME handling even if removing USE_GCC as it may
come back again in the future and be forgotten.
- Fix build on 11.3 with ports ssl. [2]
PR: 245048 [1]
PR: 243315 [2]
Submitted by: John Hein <jcfyecrayz at liamekaens.com> [2]
The bug in PR 236616 resulted in virtualbox getting pinned to llvm7. This is
less than ideal, and in-fact has been broken by improvements to
machine/atomic.h
on x86 that require a more modern compiler.
Switch the build to USE_GCC= any. The patches that were previously applied
if COMPILER_TYPE == clang are actually needed by newer GCCs as well, so make
those
standard patches instead, folding the Config.kmk patches together.
We should put some effort into testing llvm10 and working out why llvm
breaks
it, but fixing the build is more important at the moment.
Q/A:
* portlint (pre-existing issues; none in current patch)
* testport (-CURRENT, amd64)
* run testing by madpilot@
PR: 244603
Approved by: koobs (mentor), bapt (mentor)
Approved by: portmgr (blanket: build fix)
MFH: 2020Q1 (blanket: build fix)
Differential Revision: https://reviews.freebsd.org/D23967
Update xorg x11 servers to 1.20.7. This updates x11-servers/xorg-server,
xephyr, xorg-dmx, xorg-nestserver, xorg-vbserver and xwayland.
Enable the UDEV backend by default, instead of the DEVD backend, for
autoconfiguration of input devices on FreeBSD 12 and later.
FreeBSD 11 lacks the needed support in base and will keep on using the DEVD
backend.
Support for the HAL backend is dropped completely, it has been deprecated
for a long time.
Update and improve the DEVD backend.
Add a pkg message about sysctl configuration that might be needed when using
UDEV.
Use the upstream fix for glamour issues.
Use evdev xkb rules by default in xwayland [2]
Add x11-drivers/xf86-input-libinput to the list installed by default by
x11-drivers/xorg-drivers.
Fix net/tigervnc-server and emulators/virtualbox-ose
Bump portrevision of all x11 drivers, as well as other ports dependent on
xorg-server.
This represents work by many people over a long period. These include
wulf, ak, dumbbell, hselasky pete AT nomadlogic DOT org, jbeich, manu,
myself and possibly others (I tried to look through history, but might have
missed people. If so, I am sorry.)
PR: 196678 [1], 244129 [2]
Submitted by: hselasky, wulf [1], jbeich [2]
Obtained from: https://github.com/FreeBSDDesktop/freebsd-ports/tree/feature/xserver-1.20 (in part)
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: 238330
The SSL certificate of the host does not have download.virtualbox.org
in it's SubjectAltName anymore (download.virtualbox.org points to the
same CDN and is the same host as download.oracle.com, and checksums still
match).
Reported by: Duncan Young
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] 5c2cbfccf9
[2] 2ed5054e3a
[3] 009f5ebb4b
Bump all ports that depend on Qt5.
PR: 234070
Exp-run by: antoine
Approved by: kde (adridg)
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: 231590
