These are my initial build and code changes to supporting building llvm
as shared library/DLL on windows(without force exporting all symbols)
and making symbol visibility hidden by default on Linux which adding
explicit symbol visibility macros to the whole llvm codebase.
Updated cmake code to allow building llvm-shlib on windows by appending
/WHOLEARCHIVE:lib to the linker options.
Remove the hardcoded CMake error from using LLVM_BUILD_LLVM_DYLIB on
windows.
Updated CMake to define new macros to control conditional export macros
in llvm/Support/Compiler.h
Use /Zc:dllexportInlines- when compiling with clang-cl on windows with a
opt out CMake option to disable using it.
Replace some use of LLVM_EXTERNAL_VISIBILITY with new export macros.
Some of the cmake and code changes are based on @tstellar's earlier PR
https://github.com/llvm/llvm-project/pull/67502.
I have Windows building using clang-cl, while for MSVC its at-least able
to build libllvm, but some tests can't build because llvm iterator
template metaprogramming that doesn't work well with dllexport. Linux
should build without issue. My full branch is here
https://github.com/fsfod/llvm-project/tree/llvm-export-api-20.0 and
including all the auto generated export macros from clang tooling based
system.
When cross-compiling a Windows clang with `-DLLVM_BUILD_INSTRUMENTED`,
the profiling compiler-rt is linked to binaries, as one would expect,
but the profiling compiler-rt contains objects with `/DEFAULTLIB:LIBCMT`
and `/DEFAULTLIB:OLDNAMES` directives, which makes the build expect
`LIBCMT.lib` and `OLDNAMES.lib`, but they are nowhere to be found
because they are in lowercase. While the WinMsvc.cmake helper recreates
symbolic links to work around such case sensitivity issues for the
Windows SDK libs, it doesn't do so for the MSVC libs, which we add here.
ConstantFolding behaves differently depending on host's `HAS_IEE754_FLOAT128`.
LLVM should not change the behavior depending on host configurations.
This reverts commit 14c7e4a1844904f3db9b2dc93b722925a8c66b27.
(llvmorg-20-init-3262-g14c7e4a18449 and llvmorg-20-init-3498-g001e423ac626)
The intent is that the tests should not be running on PowerPC as the fp128 type
will differ. This attempts to fix the bots by using __powerpc__ instead, which
appears to be defined in godbolt.
This fixes an odd problem with the regex when `CMAKE_INSTALL_LIBDIR` is
not defined:
`string sub-command REGEX, mode REPLACE: regex "$" matched an empty
string.`
Fixesllvm/llvm-project#83802
This is a reland of (#96287). This patch attempts to reduce the reverted
patch's clang compile time by removing #includes of float128.h and
inlining convertToQuad functions instead.
This is a reland of #96287. This change makes tests in logf128.ll ignore
the sign of NaNs for negative value tests and moves an #include <cmath>
to be blocked behind #ifndef _GLIBCXX_MATH_H.
Exporting symbols from tools directory never worked with
`LLVM_EXPORT_SYMBOLS_FOR_PLUGINS=On`. When that options is on, only
symbols from the static library is linked is exported due to the export
symbols computation script. DynamicLibraryTests needs to export a symbol
from the tools/executable directory, so update it to use export list
instead.
Due to an issue mentioned in `llvm/projects/CMakeLists.txt`, libc build
is disabled by default when building with `clang-cl` on Windows. This PR
sets `LLVM_FORCE_BUILD_RUNTIME` to `ON` to bypass this limit for libc
and make libc build with `clang-cl` on Windows.
Fix the builds with LLVM_TOOL_LLVM_DRIVER_BUILD enabled.
LLVM_ENABLE_EXPORTED_SYMBOLS_IN_EXECUTABLES is not completely
compatible with export_executable_symbols as the later will be ignored
if the previous is set to NO.
Fix the issue by passing if symbols need to be exported to
llvm_add_exectuable so the link flag can be determined directly
without calling export_executable_symbols_* later.
`LLVM_ENABLE_EXPORTED_SYMBOLS_IN_EXECUTABLES` is not completely
compatible with `export_executable_symbols` as the later will be ignored
if the previous is set to NO.
Fix the issue by passing if symbols need to be exported to
`llvm_add_exectuable` so the link flag can be determined directly
without calling `export_executable_symbols_*` later.
CMake -GXcode would otherwise offer to create one scheme for each
target, which ends up being a lot. For now, limit the default to the
`check-*` LIT targets, plus `ALL_BUILD` and `install`.
For targets that aren't in the default list, we now have a configuration
variable to promote an extra list of targets into schemes, for example
`-DLLVM_XCODE_EXTRA_TARGET_SCHEMES="TargetParserTests;SupportTests"` to
add schemes for `TargetParserTests` and `SupportTests` respectively.
Summary:
The `compiler-rt` project wants `LLVM_CMAKE_DIR` but the
`llvm_ExternalProject_add` interface sets the `LLVM_CONFIG_PATH`. This
patch just makes the utility pass that as well.
When building compiler-rt with MSVC, CMAKE_INSTALL_LIBDIR and
CMAKE_INSTALL_BINDIR are empty.
This causes error in Findzstd.cmake like the following:
CMake Error at C:/llvm/cmake/modules/Findzstd.cmake:39 (string):
string sub-command REGEX, mode REPLACE: regex "$" matched an empty
string.
Do not do the REGEX when CMAKE_INSTALL_LIBDIR and CMAKE_INSTALL_BINDIR
are empty.
Similar issues were reported by others at
e7fc7540da
Debian's GCC installation has target triple "s390x-linux-gnu". Since,
unlike in Ubuntu, there is no /etc/lsb-release, config.guess detects
"s390x-ibm-linux". Generic_GCC::GCCInstallationDetector::init() only
tries to strip the "unknown" vendor, so GCC installation detection
fails.
Checking /etc/os-release in addition to /etc/lsb-release fixes this
problem. However, LLVM-built sanitizer runtimes still cannot be found:
the driver looks for them in lib/clang/19/lib/s390x-linux-gnu, but the
build system places them in lib/clang/19/lib/s390x-unknown-linux-gnu.
According to @MaskRay, the build system is doing the right thing [1]: on
the file system, full arch-vendor-os-environment triples must be used.
In order to satisfy both GCCInstallationDetector and this rule, use the
"s390x-unknown-linux-gnu" triple.
[1]
https://github.com/llvm/llvm-project/issues/95407#issuecomment-2167390240
Some Ubuntu builds were broken after 20d497c "[Driver] Remove unneeded
*-linux-gnu after D158183".
This patch by Fangrui Song fixes this with a handling in config.guess.
When doing a runtimes build with LTO using ld.bfd (or ld.gold), the
build starts failing with ninja 1.12, which added a new critical path
scheduler. The reason is that LLVMgold.so is not available yet at the
point where runtimes start being build, leading to configuration
failures in the nested cmake invocation.
Fix this by adding an explicit dependency on LLVMgold.so if it is
available. (It may not always be necessary, e.g. if the used linker is
lld, but it would be hard to detect when exactly it may or may not be
needed, so always adding the dependency is safer.)
It's useful to use toolchain files for configuring runtimes builds.
Setting `CMAKE_<LANG>_FLAGS` is however forceful and precludes initialization from the _INIT variant meant to be set by toolchains.
The toolchain file still needs to append instead of just setting and be idempotent (`include_guard()`), but this way at least a special toolchain to account for LLVM won't be required.
If built statically, `libedit` may have a private static library
dependency on a provider of the `terminfo` API (e.g., `ncurses`). This
means that multiple libraries would need to be provided as the value for
`LibEdit_LIBRARIES`, but the current implementation of `FindLibEdit`
precludes this. This PR allows a list to be passed to
`LibEdit_LIBRARIES`.
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
A follow-up to #92953. This should fix unexpected performance gains when Clang is built with GCC, and fix downstream LTO crashes reported in 4feae05c6a (r142466703)
This is a second attempt to land #84501 which failed on several targets.
This patch adds the HAS_IEE754_FLOAT128 define which makes the check for
typedef'ing float128 more precise by checking whether __uint128_t is
available and checking if the host does not use __ibm128 which is
prevalent on power pc targets and replaces IEEE754 float128s.
Update the folder titles for targets in the monorepository that have not
seen taken care of for some time. These are the folders that targets are
organized in Visual Studio and XCode
(`set_property(TARGET <target> PROPERTY FOLDER "<title>")`)
when using the respective CMake's IDE generator.
* Ensure that every target is in a folder
* Use a folder hierarchy with each LLVM subproject as a top-level folder
* Use consistent folder names between subprojects
* When using target-creating functions from AddLLVM.cmake, automatically
deduce the folder. This reduces the number of
`set_property`/`set_target_property`, but are still necessary when
`add_custom_target`, `add_executable`, `add_library`, etc. are used. A
LLVM_SUBPROJECT_TITLE definition is used for that in each subproject's
root CMakeLists.txt.
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
This patch remove 36 checks for compiler flags that are done via
invoking the compiler across LLVM, Clang, and LLDB. It's was made
possible by raising the bar for supported compilers that has been
happening over the years since the checks were added.
This is going to improve CMake configuration times. This topic was
highlighted in
https://discourse.llvm.org/t/cmake-compiler-flag-checks-are-really-slow-ideas-to-speed-them-up/78882.
Re-land 61b2a0e3336aaa0132bbed06dc185aca4ff5d2db. Some Windows builds
were failing because AArch64TargetParserDef.inc is a generated header
which is included transitively into some clang components, but this
information is not available to the build system and therefore there is
a missing edge in the dependency graph. This patch incorporates the
fixes described in ac1ffd3caca12c254e0b8c847aa8ce8e51b6cfbf/D142403.
Thanks to ExtensionSet::toLLVMFeatureList, all values of ArchExtKind
should correspond to a particular -target-feature. The valid values of
-target-feature are in turn defined by SubtargetFeature defs.
Therefore we can generate ArchExtKind from the tablegen data. This is
done by adding an Extension class which derives from SubtargetFeature.
Because the Has* FieldNames do not always correspond to the AEK_
names ("extensions", as defined in TargetParser), and AEK_ names do
not always correspond to -march strings, some additional enum entries
have been added to remap the names. I have renamed these to make the
naming consistent, but split them into a separate PR to keep the diff
reasonable (#90320)
This is a second attempt to land #84501 which failed on several targets.
This patch adds the HAS_IEE754_FLOAT128 define which makes the check for
typedef'ing float128 more precise by checking whether __uint128_t is available
and checking if the host does not use __ibm128 which is prevalent on power pc
targets and replaces IEEE754 float128s.
This patch enables constant folding for 128 bit floating-point logf
calls. This is achieved by querying if the host system has the logf128()
symbol available with a CMake test. If so, replace the runtime call with
the compile time value returned from logf128.
* It is possible to setup llvm-project builds without going through
`llvm/CMakeList.txt` so the fatal error handling should be smarter.
* Disable option on Apple style lldb-linux builds.
Building the Apple way turns off plugin support, meaning we don't need
to export unloadable symbols from all executables. While deadstripping
effects aren't expected to change, enabling this across all tools
prevents the creation of export tries. This saves us ~3.5 MB in just the
universal build of `clang`.
