| commit | 919fcd11ad53bdfab9a14d5df6de0895bf24e456 | [log] [tgz] |
|---|---|---|
| author | Khem Raj <raj.khem@gmail.com> | Tue Oct 28 19:02:44 2025 -0700 |
| committer | Khem Raj <raj.khem@gmail.com> | Tue Oct 28 19:02:44 2025 -0700 |
| tree | e5f74a835996102985f1e6d9e83bfb8a004a753b | |
| parent | d21ab66fd88377ee4a9247e67b28cadfeed4bd3b [diff] |
[llvm-libgcc] Fix libgcc.a symlink path when LLVM_ENABLE_PER_TARGET_RUNTIME_DIR=OFF The llvm-libgcc installation was creating incorrect symlinks for libgcc.a when built with LLVM_ENABLE_PER_TARGET_RUNTIME_DIR=OFF, particularly seen with Yocto cross-compilation environments. Issues seen: - Absolute path in symlink: The previous code didn't handle absolute paths returned by get_compiler_rt_install_dir() in staging/sysroot environments, resulting in symlinks like: libgcc.a -> /absolute/path/to/sysroot/usr/lib/clang/.../libclang_rt.builtins.a - Missing architecture suffix: When the install path contained "clang", the code would skip setting builtins_suffix, creating: libgcc.a -> clang/21.1.4/lib/linux/libclang_rt.builtins.a instead of: libgcc.a -> clang/21.1.4/lib/linux/libclang_rt.builtins-aarch64.a - Incorrect relative path calculation: The original regex stripped too much or too little of the path, either creating symlinks pointing to non-existent locations or stripping the clang/ directory prefix entirely. Solution: - Extract the relative path starting from 'clang/' when present in absolute paths, ensuring the symlink points to the correct location within the installation hierarchy - Always append the architecture suffix to the builtins library name - Only prepend '../' to the path when LLVM_ENABLE_PER_TARGET_RUNTIME_DIR is enabled, as this is when the builtins are in a different directory level The symlink now correctly points to the existing compiler-rt builtins library without creating duplicate copies. Tested with LLVM_ENABLE_PER_TARGET_RUNTIME_DIR=OFF in cross-compilation environments (aarch64 target).
Welcome to the LLVM project!
This repository contains the source code for LLVM, a toolkit for the construction of highly optimized compilers, optimizers, and run-time environments.
The LLVM project has multiple components. The core of the project is itself called “LLVM”. This contains all of the tools, libraries, and header files needed to process intermediate representations and convert them into object files. Tools include an assembler, disassembler, bitcode analyzer, and bitcode optimizer.
C-like languages use the Clang frontend. This component compiles C, C++, Objective-C, and Objective-C++ code into LLVM bitcode -- and from there into object files, using LLVM.
Other components include: the libc++ C++ standard library, the LLD linker, and more.
Consult the Getting Started with LLVM page for information on building and running LLVM.
For information on how to contribute to the LLVM project, please take a look at the Contributing to LLVM guide.
Join the LLVM Discourse forums, Discord chat, LLVM Office Hours or Regular sync-ups.
The LLVM project has adopted a code of conduct for participants to all modes of communication within the project.