where we need a way to get to gcc-libs/libestdc++. This happened to
work so far except when it didn't (slight differences between built
and already installed llvm packages, maybe?), as found the hard way by
cwen@.
Our COMPILER support automatically amends WANTLIB and LIB_DEPENDS, so
use those to explicitely set:
- WANTLIB-main and WANTLIB-lldb
- LIB_DEPENDS-main and LIB_DEPENDS-lldb
The clang-tools-extra package contains helpful developer tools using
Clang's APIs.
Initial diff from me, further work by jca@ with feedback from sthen@.
OK jca@ and @sthen
* switch gcc4 module to gcc/8
* register the gcc/8 subpackages as updates for their gcc/4.9 counterparts
* sync the gcc version in devel/llvm
* add a quirk entry that gcj is obsolete
* unhook 4.9 from the build
Preparatory work by many.
ok sthen@
All the work done by Brad except for some fixes from base by mortimer@
and patrick@
Tests: amd64 Brad, jsg@ and me, i386: Brad, mips64: visa@, sparc64 me.
No tests on powerpc but a test build with only the PowerPC backend
packages on amd64.
- don't build clang itself with -fno-ret-protector and -mno-retpoline,
to regain performance
- use -mretpoline by default on amd64
- fix printf %b length specifiers
from Brad
On non-clang archs, ports-clang uses the libestdc++ backend from
ports-gcc, so it needs the headers in the g++ package at runtime.
Testing CHOSEN_COMPILER == "ports-gcc" is nice semantically but since it
happens after including bsd.port.mk, it's too late to change TEST/RUN_DEPENDS.
Use a different test that may not be optimal but works in practice, so that
the dep is correctly registered.
This should fix random build failures due to dpb junking in bulk builds
on non-clang archs.
Problem pointed out by Goerge Koehler, ok sthen@
Using long calls means slower code. It is not useful right now because
the size of the llvm executables has been reduced, as shown by tests by
Charlene Wendling. And it breaks compilation with gcc 6, as pointed out
by a report from George Koehler.
The goal is to provide quick feedback on proposed diffs, and enforce
testing on at least one gcc arch (probably sparc64) before diffs get
committed. All contributions are still welcome.
Maintainer timeout, ok ajacoutot@ visa@ naddy@ sthen@ espie@
build with ports-gcc which isn't yet in shape to build LLDB.
tests and tweaks from various people including jca@, landry@,
Charlene Wendling, and probably others -- ok jca@
- [mips] Prevent PIC to be set to level 2
- [mips] Improve handling of -fno-[pic/PIC] option
- [PowerPC] Set the default PLT mode on OpenBSD/powerpc to Secure PLT.
- Remove PowerPC -nopie workaround
- Add workaround to PowerPC to only build the PowerPC backend as a means
of reducing the code size
- Enable building on PowerPC
from Brad (maintainer)
This allows building webkitgtk4 on OpenBSD/powerpc
- Accept both `--foo bar` and `--foo=bar` styles options.
- Add support for -z initfirst.
- Generate __data_start symbol that marks the start of .data when __data_start
is referenced from code being linked.
From Brad (maintainer)
When merging sections into the output, lld tries to adjust the alignment of
the section to be at least as large as the entry size of the section.
This causes a later check that validates the alignment to fail if the
entry size isn't a power of two. This happens when building some of the
java support code in ports gcc. Fix this by sticking to the original
alignment if the entry size isn't a power of two.
from Brad (maintainer)
Allow preemption of functions with protected visibility. Disallowing this
makes no sense. Yes it breaks function address equality and therefore
the expectations of the standard C language. However declaring symbols
with protected visibility isn't standard C in the first place.
from Brad (maintainer)
dependent ports, this restricts deps to use the current clang version
which is required for some ports using the unversioned libLLVM*.so
library. see https://marc.info/?l=openbsd-ports&m=152377935312657&w=2
- set RUN_DEPENDS on devel/llvm in lang/crystal as it uses libLLVM*.so
breakage reported by James Turner
I don't like this at all, but don't see what other option we have,
if anyone has a better idea please pipe up.
