Relates to https://github.com/llvm/llvm-project/issues/54337
This is just a comment referencing distutils but even so, we can ditch
the custom which and use the one Python 3.3 added. Which has the .bat
bug fixed:
https://docs.python.org/3.3/library/shutil.html#shutil.which
I tested this on Windows:
```
C:\Users\tcwg>touch foo.bat
C:\Users\tcwg>python
Python 3.11.9 (tags/v3.11.9:de54cf5, Apr 2 2024, 12:24:25) [MSC v.1938 64 bit (ARM64)] on win32 Type "help", "copyright", "credits" or "license" for more information.
>>> import shutil
>>> shutil.which("foo")
'.\\foo.BAT'
```
I just ran the script manually and got reasonable results, I haven't
done a GN build.
Bumping the deployment target from macOS 10.10 to 12 enables chained
fixups and DWARF 4 debug information for the LLVM binaries and
libraries.
Like in Chromium, a GN arg (`mac_deployment_target`) is added to allow
overriding the default.
Without this, the doc string is put in a single line. These
scripts have multi-line docstrings, so this makes their --help
output look much nicer.
Otherwise, no behavior change.
If the GN arg `sysroot` was set to a root-relative path like e.g.
`"//sysroot"`, we weren't rebasing it correctly, leading to
warnings from clang about it ignoring a non-existent sysroot.
Similar to 6073f87d7f160.
This reverts commit fe82a3da36196157c0caa1ef2505186782f750d1.
This broke LLDB on MacOS due to a missing symbol during linking.
The fix has been applied in c6c08eee37bada190bd1aa4593c88a5e2c8cdaac.
Original commit message:
The terminfo dependency introduces a significant nonhermeticity into the
build. It doesn't respect `--no-undefined-version` meaning that it's not
a dependency that can be built with Clang 17+. This forces maintainers
of source-based distributions to implement patches or ignore linker
errors.
Remove it to reduce the closure size and improve portability of
LLVM-based tools. Users can still use command line arguments to toggle
color support expliticly.
Fixes#75490Closes#53294#23355
The terminfo dependency introduces a significant nonhermeticity into the
build. It doesn't respect `--no-undefined-version` meaning that it's not
a dependency that can be built with Clang 17+. This forces maintainers
of source-based distributions to implement patches or ignore linker
errors.
Remove it to reduce the closure size and improve portability of
LLVM-based tools. Users can still use command line arguments to toggle
color support expliticly.
Fixes#75490Closes#53294#23355
Remove --unwindlib=none flag that was added by D143598. It is required
to not pass this flag when linking binaries. With this flag, linking
e.g. llvm-symbolizer will fail.
There was a missing dependency from most targets to the implicitly linked
libraries (libunwind and builtins), which was causing the build for those
targets to fail when they were built on their own. I never noticed this
because I always build the implicitly linked libraries together with
their dependencies. Make the dependency explicit by introducing a new
target //llvm/utils/gn/build/libs/implicit representing the platform's
implicitly linked libraries, and depend on that from the LLVM libraries,
so that "normal" binaries like llvm-symbolizer will have all of their
dependencies available.
D143598 set the arch subdirectory to i686 for Android. However, the arch
subdirectory on Android is i386, and has been for a long time.
$ find android-ndk-r* -name i386
android-ndk-r18b/toolchains/llvm/prebuilt/linux-x86_64/lib64/clang/7.0.2/lib/linux/i386
android-ndk-r19/toolchains/llvm/prebuilt/linux-x86_64/lib64/clang/8.0.2/lib/linux/i386
android-ndk-r20/toolchains/llvm/prebuilt/linux-x86_64/lib64/clang/8.0.7/lib/linux/i386
android-ndk-r21-beta1/toolchains/llvm/prebuilt/linux-x86_64/lib64/clang/9.0.8/lib/linux/i386
android-ndk-r21d/toolchains/llvm/prebuilt/linux-x86_64/lib64/clang/9.0.8/lib/linux/i386
android-ndk-r22/toolchains/llvm/prebuilt/linux-x86_64/lib64/clang/11.0.5/lib/linux/i386
android-ndk-r23-beta5/toolchains/llvm/prebuilt/linux-x86_64/lib64/clang/12.0.5/lib/linux/i386
android-ndk-r24/toolchains/llvm/prebuilt/linux-x86_64/lib64/clang/14.0.1/lib/linux/i386
android-ndk-r25c/toolchains/llvm/prebuilt/linux-x86_64/lib64/clang/14.0.7/lib/linux/i386
Using the wrong name prevents Clang from being able to find libunwind.a on
x86. Fix the code to use i386 as the arch subdirectory, consistent with
the NDK.
Bring back -Wl,-z,defs which was removed for Android by D143598, presumably
because of the missing unwind library.
Differential Revision: https://reviews.llvm.org/D146266
Only supports ASAN mode right now. Standalone requires a some more plumbing so it will be a follow-up.
Mac-only but I suspect this will be fine on Linux also since it's based on the check-asan file, will follow up after testing.
Differential Revision: https://reviews.llvm.org/D153651
Adds build files for libraries, tools, and tests -- everything except
the runtime.
Doesn't hook up bolt in the main BUILD.gn file yet -- I want to verify
that it builds on Linux, macOS, Windows before doing that. (I've only
checked on macOS so far.)
`ninja check-bolt` passes on macOS with this.
(I locally bumped the deployment target to macOS 10.12 for that. bolt/ uses
std::mutex quite a bit, which requires 10.12.)
Differential Revision: https://reviews.llvm.org/D138355
After bc39d7bdd497 (ported to GN in 94c00c10e), libclang uses symbol_exports,
and clang/test/LibClang/symbols.test wants the versioned name to be `LLVM_[0-9]$`
instead of `FOO`.
The two flags do the same thing, but the OS is called macOS these days.
(The new flag is 5 years old: https://reviews.llvm.org/D32796)
No behavior change.
`use_ubsan=true` seems to Just Work on macOS, so allow it.
https://reviews.llvm.org/D122862 broke use_asan=true, use_tsan=true, and
use_ubsan=true builds on Linux too. This makes this go again by explicitly
disabling asan, tsan, and ubsan for the baremetal part of the build. See
discussion on https://reviews.llvm.org/D122862 for other possible approaches.
Differential Revision: https://reviews.llvm.org/D127906
After years of tablegen being the only host binary we run as part
of the build, we're now in the process of growing at least two more:
- make_confusable_table (https://reviews.llvm.org/rG180bae08a04d)
- pseudo-gen (not yet fully hooked up in the GN build, but I have
a local branch that hooks it up)
Factor out the few lines we need for running a host binary as part of the
build.
No behavior change.
Differential Revision: https://reviews.llvm.org/D126963
This reverts commit e2ee8bf9818189b900e65d6ea8f1ae6fc75455ce.
This change is beyond my ability to integrate into Google's internal
build configuration tonight.
Currently, the Bazel build uses static, checked in [llvm-]config.h files
in combination with global macro definitions to mimic CMake's generated
headers. This change reuses the write_cmake_config.py script from the GN
build to generate the headers from source in the same way. The purpose
is to ensure that the Bazel build stays up to date with any changes to
the CMake config files. The write_cmake_config.py script has good error
checking to ensure that unneeded, stale variables are not passed, and
that any missing variables are reported as errors.
I tried to closely follow the logic in the GN build here:
llvm/utils/gn/secondary/llvm/include/Config/BUILD.gn
The duplication between this file and config.bzl is significant, and we
could consider going further, but I'd like to hold off on it for now.
The GN build changes are to move the write_cmake_config.py script up to
//llvm/utils/write_cmake_config.py, and update the paths accordingly.
The next logical change is to generate Clang's config.h header.
Differential Revision: https://reviews.llvm.org/D126581
Only applies linux for now.
This prevents warnings with use_thinlto like
bfd plugin: LLVM gold plugin has failed to create LTO module: Not an int attribute (Producer: 'LLVM15.0.0git' Reader: 'LLVM 13.0.1')
Reviewed By: thakis
Differential Revision: https://reviews.llvm.org/D125399
