Age | Commit message (Collapse) | Author |
|
to produce 99+% correct code at all optimization levels, and can help people
who would like to tinker a bit with the backend.
(note m88k ports still use gcc 3 at the moment)
|
|
Apparently favored by deraadt@, pointed out by patrick@, ok patrick@
|
|
Shaves off a significant amount of time (eg on riscv64) in base builds.
If you want to build gnu/usr.bin/clang from source you'll need
bsd.own.mk rev 1.213 installed.
ok miod@ patrick@
|
|
source
Pointed out by sthen@
While make build indeed takes care of running make install in share/mk,
running make obj first would error out when encountering the unknown
BUILD_LLDB variable. I can wait a few days before committing this again.
|
|
Apparently favored by deraadt@, pointed out by patrick@, ok patrick@
|
|
Shaves off a significant amount of time (eg on riscv64) in base builds.
Note that you'll need bsd.own.mk rev 1.213 (which make build should take
care of).
ok miod@ patrick@
|
|
ok fcambus@, sthen@
|
|
Over a decade ago, the build infrastructure had special logic to process
man pages that ended with the suffix "tbl".
This infrastructure is long gone and the special naming for these man pages
is no longer needed.
Revert the naming of these man pages for consistency with all other man
pages in the tree. As a bonus, we remove a few lines from some of the
Makefiles making them simpler.
ok jmc@, and no objection from schwarze@
|
|
Useful on architectures not actually supported by our ancient binutils
(arm64, powerpc64, riscv64), or on architectures incompletely supported
(eg recent features on amd64).
ok kettenis@ sthen@
|
|
|
|
|
|
Drop NOPIE_FLAGS = -fPIE and change CFLAGS on powerpc to be the same
as on other arches.
ok deraadt@ kettenis@
|
|
ok sthen@, tb@
|
|
They failed if there was nothing to clean.
The test target now depends on the all target so we have something
to run tests against. They still don't like to pass in-tree,
but that is a separate issue.
Noticed by deraadt@, suggestions and improvements from geunther@ and bluhm@
|
|
zlib has a crashing bug. The bug fix has been sitting in the
unreleased develop branch for nearly four years. Pull in this fix
and a small followup.
same fix as in base lib/libz
|
|
again. The header zlib.h in our base uses z_off_t for fields
total_in and total_out in struct z_stream_s. The rest of the world
uses uLong there. This leads to an incompatibility when comiled
with Perl. The pkg tools fail on i386.
debugged by semarie@; discussed with tb@
|
|
instead of the sources that are packaged with Perl. This allows
us to apply security fixes for userland base in one place. Zlib.so
is used with dlopen(3) and gets a new library dependency to libz.
Before zlib objects from zlib-src were linked statically.
OK tb@
|
|
|
|
|
|
other
|
|
This lets lld link code with object files created with ld -b binary,
as used by several ports (mupdf, postgresql-pllua, various games).
Upstream report with an unfinished diff: https://reviews.llvm.org/D106378
ok kettenis@
|
|
ok hackroom
tested by plenty
|
|
ok deraadt@
|
|
This was r1.2 and accidentally lost in the update to Devel::PPPort 3.64.
|
|
E.g. `cc --print-file-name libc.so` reports /usr/lib/libc.so.96.1
This is a complement of the major.minor finding logic in DriverUtils.
`ld -lc -L/usr/lib` currently find the libraries with this logic.
To make things more obviously related the code was extracted into a
function which was copied over verbatim.
fine with mortimer@
ok patrick@
|
|
ok hackroom
tested by plenty
|
|
Fixes backtraces on i386 (tested by bluhm) and armv7.
OK bluhm@
|
|
ok hackroom
tested by plenty
|
|
Sync our hardcoded config with what cmake detects in ports/devel/llvm.
Brought up privately by cheloha@, then by Andrei on tech@, input and ok
gnezdo@
|
|
riscv64 family of platforms, so we don't try to build there.
However we mis-nested the arch check, causing some unintended side effects,
most notably installing binutils-2.17's ar(1) which overwrote the
intended llvm-ar(1).
Fix the if nesting so it only applies where intended.
tested on aarch64 by me, powerpc64 by gkoehler@, and riscv64 by jca@
OK miod@ robert@ gkoehler@ jca@
|
|
|
|
avoid -Wno-compound-token-split-by-macro warnings from clang 13.
OK afresh1@
|
|
ok jca@
|
|
ok jca@
|
|
ok kettenis@
|
|
13.0.0 produces thousands of -Wcompound-token-split-by-macro warnings
wir older ppport.h header files. They are especially frequent in
the ports tree. After this update we can use perl -MDevel::PPPort
-e'Devel::PPPort::WriteFile' to regenerate the ppport.h files. Then
we have a version that is recent enough to build all ports and does
not spit out tons of warnings.
discussed with espie@ sthen@; OK afresh1@
|
|
Timing is good deraadt@, OK sthen@
|
|
looking good sthen@, Great! bluhm@
|
|
is a no-op; ok millert@
|
|
ok hackroom
tested by plenty
|
|
ok patrick@ kettenis@
|
|
https://github.com/llvm/llvm-project/commit/52bfd2c1ccd86ff813ee6df5a6700690acdd912f
This fixes an issue introduced in D101996.
A weak reference in a shared library could be incorrectly reported if
there is another library that has a strong reference to the same symbol.
Differential Revision: https://reviews.llvm.org/D115041
ok patrick@ kettenis@
|
|
ok hackroom
tested by plenty
|
|
through -moutline-atomics. These are included by default in this updated
version of compiler-rt, we just haven't enabled them yet. Some ports start
to make use of that option, so it makes sense to provide these helpers.
The helpers would make use of the ARMv8.1 LSE instructions, if we flagged
that the running system supports those. As we do not yet have a mechanism
to show support for LSE, the code will always fall back to regular atomics.
Issue raised by jca@
Tested by phessler@
Input from jsg@
ok kettenis@
|
|
readelf -d for displaying them.
(lld 13 sets DF_1_PIE on most our binaries)
ok jsg@
|
|
conversion specifier to mean 'll'. Found by an ok deraadt@
|
|
As pointed out by deraadt@ we can do better than ask people to follow
instructions. Note that you still need an up-to-date clang if you
update your kernel Makefiles, as those use clang13-only options.
Also -Werror doesn't bring much in binutils context. It's an outdated
codebase with lots of warts, which frequently breaks due to -Werror
during clang updates.
"This is the right fix" deraadt@
|
|
with LLVM 13.
|
|
|
|
|