| Age | Commit message (Collapse) | Author |
|---|
|
Now that we use the native compiler, and have fixed Qt, and these vars
are unset it Guix, we can remove the unsetting from our compiler command
here.
Fixes #21552.
|
|
Whilst these remain aliases for each other, the later is preferred,
and I assume the former will be removed at some point in the future;
see: https://github.com/llvm/llvm-project/pull/95374.
|
|
Change some references to the macho ld64 to lld, which is now what is
used.
|
|
|
|
|
|
|
|
|
|
Adjust the security check for:
ld64.lld: warning: Option `-allow_stack_execute' is not yet implemented.
ld64.lld: error: -fixup_chains is incompatible with -no_pie
and to account for the embedding of LLVMs version number.
|
|
Only build ld64 from cctools.
Disable adhoc codesigning, to avoid non-determinism.
|
|
Similar to libtool, (llvm-)otool only exists with a version suffix
on some systems (Ubuntu), which makes it annoying to use/find. Avoid
this, by switching to objdump. Which is a drop-in replacement.
This is related to #21778, and the switchover to using vanilla LLVM for
macOS.
|
|
This is only needed when compiling on macOS. This means we can also
better scope the usage of `-headerpad_max_install_names`.
|
|
|
|
Note that this is completely unrelated to gnu usage of libtool.
|
|
This doesn't need to exist in C & CXX.
|
|
|
|
This has outlived its usefulness, doesn't gel well with
newer compilers & `-flto` related options, i.e thin vs full, or `=auto`,
and having `-flto` as the only option means that sometimes this just
needs to be worked around, i.e in oss-fuzz:
https://github.com/google/oss-fuzz/blob/master/projects/bitcoin-core/build.sh.
While it was convenient when `-flto` was newer, support for `-flto` is now
in all compilers we use, and there's also no-longer any real need
for us to treat `-flto` different to any other optimization option.
Remove it, to remove build complexity, and so there's no need
to port a similar option to CMake.
Note that the LTO option remains in depends, because we still a way to
build packages that have LTO specific patches/options.
If we decide to merge this, I'll follow up downstream in oss-fuzz first,
to make sure we don't break the build.
|
|
|
|
```bash
-platform_version platform min_version sdk_version
This is set to indicate the platform, oldest supported version
of that platform that output is to be used on, and the SDK that
the output was built against.
```
|
|
I forgot to do this in 7d5815293ed8a3dea68b61a78944e410f02b147f.
|
|
This is necessary as the new fixup_chains linker behavior is only valid
when the runtime target is >=11.0.
|
|
Fixes builds with llvm >= 11 in guix by working around the problem. As a bonus,
this is much cleaner and more maintainable than what we had before.
|
|
Use of -stdlib++-isystem gets rid of any system c++ header include paths and
negates the need for this option. In newer versions of clangs the combo
produces a warning.
|
|
For some reason the previous syntax worked with clang 15 and below, but
clang 16 requires that the option and value are properly separated.
|
|
Use lto.h from clang+llvm not libtapi. The later is older,
and comes bundled with the libtapi repo.
Copy libLTO.so when building with FORCE_USE_SYSTEM_CLANG.
|
|
|
|
|
|
No Qt for now.
|
|
|
|
This should be sufficient to support building for Apple ARM when
cross-compiling.
|
|
This is required to use std::filesystem on macOS as support for it only
landed in the libc++ dylib shipped with 10.15.
See also: https://developer.apple.com/documentation/xcode-release-notes/xcode-11-release-notes
Clang now supports the C++17 <filesystem> library for iOS 13, macOS 10.15, watchOS 6, and tvOS 13.
|
|
|
|
|
|
|
|
|
|
|
|
See previous commit for description.
|
|
Instead of doing the awkward /bin path prepending at config.site
creation time, set darwin_{CC,CXX} in a way that fully determines the
program's path (clang/clang++) similar to how AC_PATH_{TOOL,PROG} would
do.
Also see the added comment block in depends/Makefile for more context on
determining $PATH for our config.site.
|
|
clang warns when a command line option is unused, and some of our tests
use Werror, so unfortunately we cannot use this flag to pin our linker
for now. Leaving this commit in for future reference, as it would be
great if there's more granularity to Werror and we can be explicit about
what linker we want to use.
|
|
|
|
|
|
|
|
For depends builds this was fixed by fbcfcf69, which deleted the conflicting
headers. When we no longer control the clang installation, we need to ensure
that the SDK's libc++ headers are used rather than the ones shipped with clang.
We can do that by turning off the default include path and hard-coding our own.
This hard-coded path is ok because we control (via SDK packaging) where these
headers end-up.
Side-note: Now that this path is hard-coded in depends, we can potentially
package the SDK differently, as the c++ folder can live wherever is most
convenient for us.
|
|
|
|
For now they remain the same, but in the next commit, we will assign
them differently according to wether or not we're using system clang.
|
|
|
|
Without this clang fails to add any newly-added linker features.
Removing this in ca5055a5aa07aba81a87cf12f6f0526a63c423b5 was likely a
regression.
See https://github.com/bitcoin/bitcoin/pull/19240#issuecomment-647764049
for more discussion.
|
|
This gets us a newer SDK with c++17 support and retains 10.12
back-compat.
Co-authored-by: Carl Dong <contact@carldong.me>
|
|
|
|
Builds required packages and passes --enable-multiprocess option to bitcoin build
|
|
Co-Authored-By: Carl Dong <accounts@carldong.me>
|
