Skip to content

Conversation

@zjlcd
Copy link

@zjlcd zjlcd commented Nov 17, 2025

standalone build llvm flang-rt need some cmake environment, This patch improves the CMake environment required for standalone build. and a typical installation script is described as follows:

build-flangrt.sh

#!/usr/bin/bash
work_dir=`pwd`
install_dir=$work_dir/install
ROOTDIR=$work_dir/llvm-project

cd $work_dir
cd llvm-project/flang-rt
rm -rf build
mkdir build
cd build
cmake -G "Unix Makefiles" \
      -S $ROOTDIR/runtimes \
      -DCMAKE_CXX_STANDARD=17 \
      -DLLVM_RUNTIMES_BUILD=yes \
      -DFLANG_RUNTIME_F128_MATH_LIB="libquadmath" \
      -DCMAKE_BUILD_TYPE=Release \
      -DLLVM_TARGET_TRIPLE="x86_64-unknown-linux-gnu" \
      -DLLVM_BINARY_DIR=$ROOTDIR/build \
      -DCMAKE_INSTALL_PREFIX=$install_dir \
      -DCMAKE_C_COMPILER=/usr/bin/gcc \
      -DCMAKE_CXX_COMPILER=/usr/bin/g++ \
      -DCMAKE_Fortran_COMPILER=$install_dir/bin/flang \
      -DCMAKE_Fortran_COMPILER_WORKS=yes \
      -DLLVM_INSTALL_TOOLCHAIN_ONLY=ON \
      ..

make -j16
make install

@github-actions
Copy link

Thank you for submitting a Pull Request (PR) to the LLVM Project!

This PR will be automatically labeled and the relevant teams will be notified.

If you wish to, you can add reviewers by using the "Reviewers" section on this page.

If this is not working for you, it is probably because you do not have write permissions for the repository. In which case you can instead tag reviewers by name in a comment by using @ followed by their GitHub username.

If you have received no comments on your PR for a week, you can request a review by "ping"ing the PR by adding a comment “Ping”. The common courtesy "ping" rate is once a week. Please remember that you are asking for valuable time from other developers.

If you have further questions, they may be answered by the LLVM GitHub User Guide.

You can also ask questions in a comment on this PR, on the LLVM Discord or on the forums.

@zjlcd zjlcd marked this pull request as draft November 17, 2025 06:36
@zjlcd zjlcd marked this pull request as ready for review November 17, 2025 06:38
@zjlcd
Copy link
Author

zjlcd commented Nov 17, 2025

Hi @vzakhari, @wangzpgi , @sscalpone and @jeanPerier , I've submitted a PR for standalone llvm flang-rt build。Could you please help review this change when you have a moment? Thank you!”

@Meinersbur
Copy link
Member

Building Flang-Rt in a "default build" (this is how the libcxx folks decided to a call a build with https://github.com/llvm/llvm-project/blob/main/runtimes/CMakeLists.txt as top-level build instruction) already works and is documented. What does this PR improve in top of that?

@zjlcd
Copy link
Author

zjlcd commented Nov 18, 2025

Building Flang-Rt in a "default build" (this is how the libcxx folks decided to a call a build with https://github.com/llvm/llvm-project/blob/main/runtimes/CMakeLists.txt as top-level build instruction) already works and is documented. What does this PR improve in top of that?

Well, Thank you very much for your feedback, Your comment is absolutely correct. Please allow me to provide some explanation for this PR, When I read the Standalone Runtimes Build section of the README file(https://github.com/llvm/llvm-project/blob/main/flang-rt/README.md#standalone-runtimes-build), I tried to standalone build flang-rt project as described(the standalone build script was provided at the beginning.), However, I got some configuration errors as follows:

image image image

Therefore, I tried to fix these CMake configuration issues, and attempted to help friends who might be puzzled by this problem. Thanks again.

Copy link
Member

@Meinersbur Meinersbur left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I cannot reproduce a problem with the current runtimes-default ("standalone") build. Some tasks such as amending CMAKE_MODULE_PATH is already appended by the top-level runtimes/CMakeLists.txt script, as well as cmake_minimum_required and include(CheckCXXCompilerFlag). IN_LIST -> list(FIND ...) seems equivalent. CMAKE_Fortran_COMPILER_FORCED is, when it is what I think it is, deprecated in CMake and should not be used.

.gitignore is something global and should handled in https://github.com/llvm/llvm-project/blob/main/.gitignore, not per-project.

Although your script says -S $ROOTDIR/runtimes, it is missing -DLLVM_ENABLE_RUNTIMES=flang-rt mentioned in the instruction and therefore will not compile any runtime. I assume you using flang-rt/CMakeLists as top-level CMake file. You even explicitly skipped over the big error message that tells you how to do it correctly by adding -DLLVM_RUNTIMES_BUILD=ON.

list(APPEND CMAKE_MODULE_PATH
"${FLANG_RT_SOURCE_DIR}/cmake/modules"
"${FLANG_SOURCE_DIR}/cmake/modules"
"${FLANG_SOURCE_DIR}/../cmake/Modules"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@zjlcd
Copy link
Author

zjlcd commented Nov 21, 2025

Okay, I think I completely understand what you mean. I’m trying to provide more details to explain my motivation.
When I learned that the llvm-project/compiler-rt project can be build either by using llvm-project/runtimes/CMakeLists.txt(https://github.com/llvm/llvm-project/blob/main/runtimes/CMakeLists.txt#L30) or by using llvm-project/compiler-rt/CMakeLists.txt(https://github.com/llvm/llvm-project/blob/main/compiler-rt/CMakeLists.txt) as the top-level CMake file, I tried both methods and got desired result with both. Therefore, I am trying to got the same results with the flang-rt project. in my humble opinion, the two projects should have similarities, at least in the build method.

As you described, using llvm-project/runtimes/CMakeLists.txt(https://github.com/llvm/llvm-project/blob/main/runtimes/CMakeLists.txt#L30) as the top-level CMake file to build flang-rt went very smoothly. Later, I tried to using llvm-project/flang-rt/CMakeLists.txt as the top-level CMake file and got the troubles mentioned above. In the build-flangrt.sh script, my description may have been inaccurate, causing you some confusion, for which I apologize.

using llvm-project/runtimes/CMakeLists.txt as the top-level CMake file, runtimes-flangrt.sh:

#!/usr/bin/bash
work_dir=`pwd`
install_dir=$work_dir/install
ROOTDIR=$work_dir/llvm-project

cd $work_dir
cd llvm-project
cd runtimes
rm -rf build
mkdir build
cd build
cmake -G "Unix Makefiles" \
      -S $ROOTDIR/runtimes \
      -DLLVM_BINARY_DIR=$ROOTDIR/build \
      -DCMAKE_Fortran_COMPILER=$install_dir/bin/flang \
      -DCMAKE_Fortran_COMPILER_WORKS=yes \
      -DLLVM_ENABLE_RUNTIMES=flang-rt \
      -DLLVM_RUNTIMES_BUILD=ON \
      -DFLANG_RUNTIME_F128_MATH_LIB="libquadmath" \
      -DCMAKE_C_COMPILER=/usr/bin/gcc \
      -DCMAKE_CXX_COMPILER=/usr/bin/g++ \
      -DLLVM_TARGET_TRIPLE="x86_64-unknown-linux-gnu" \
      -DCMAKE_INSTALL_PREFIX=$install_dir \
      ..

make -j16
make install

This script works smoothly.

new build-flangrt.sh:

#!/usr/bin/bash
work_dir=`pwd`
install_dir=$work_dir/install
ROOTDIR=$work_dir/llvm-project


cd $work_dir
cd llvm-project/flang-rt
rm -rf build
mkdir build
cd build
cmake -G "Unix Makefiles" \
      -DLLVM_ENABLE_RUNTIMES=flang-rt \
      -DLLVM_RUNTIMES_BUILD=ON \
      -DCMAKE_CXX_STANDARD=17 \
      -DLLVM_RUNTIMES_BUILD=yes \
      -DFLANG_RUNTIME_F128_MATH_LIB="libquadmath" \
      -DCMAKE_BUILD_TYPE=Release \
      -DLLVM_TARGET_TRIPLE="x86_64-unknown-linux-gnu" \
      -DLLVM_BINARY_DIR=$ROOTDIR/build \
      -DCMAKE_INSTALL_PREFIX=$install_dir \
      -DCMAKE_C_COMPILER=/usr/bin/gcc \
      -DCMAKE_CXX_COMPILER=/usr/bin/g++ \
      -DCMAKE_Fortran_COMPILER=$install_dir/bin/flang \
      -DCMAKE_Fortran_COMPILER_WORKS=yes \
      -DLLVM_INSTALL_TOOLCHAIN_ONLY=ON \
      ..

make -j16
make install

This script can not got desired result unless the patch is applied to flang-rt. and as for why deprecated CMake statements are used, it is to support older versions of CMake, but it seems that in the flang-rt project latest commit, such "deprecated statements" changes are no longer necessary(to be verified). -DLLVM_RUNTIMES_BUILD=ON doesn't work at the moment.

Thanks again.

@Meinersbur
Copy link
Member

The number of ways that flang-rt can built ("build modes") should be minimized. Every build modes induces maintanance overhead. Whenever there is a change to a CMakeLists.txt, one must ensure it continues to work in all build modes. Few developers actually do this so it constantly breaks. So introducing a build mode requres good justification and I don't see what could be done in a standalone build-mode that cannot also be done in a runtimes-default build mode. compiler-rt it also trying to reduce its number of build modes: #124012. AFAIK, there isn't any buildbot left that even test whether compiler-rt's standalone mode is still working.

Consider seeing https://github.com/llvm/llvm-project/blob/main/runtimes/CMakeLists.txt just as the boilerplate code needed for an LLVM-runtime, just like the files in https://github.com/llvm/llvm-project/tree/main/cmake/Modules and https://github.com/llvm/llvm-project/tree/main/cmake/Modules with the difference that it is not include()d from the runtimes, but used as a "driver". A separate standalone mode would just require duplicating this boilerplate again into flang-rt's (and every other runtime's) CMakeLists.txt.

What could be done is refactoring that boilerplate into a separate file such as LLVMRuntimes.cmake. The remaining boilerplate for https://github.com/llvm/llvm-project/blob/main/runtimes/CMakeLists.txt would mabe be

project(Runtimes C CXX ASM)
list(INSERT CMAKE_MODULE_PATH 0
  "${CMAKE_CURRENT_SOURCE_DIR}/cmake"
)
include(LLVMRuntimes)

and for each runtime:

if (CMAKE_SOURCE_DIR STREQUAL CMAKE_CURRENT_SOURCE_DIR)
  project(flang-rt C CXX ASM)
  set(LLVM_ENABLE_RUNTIMES "flang-rt")
  list(INSERT CMAKE_MODULE_PATH 0
    "${CMAKE_CURRENT_SOURCE_DIR}/../runtimes/cmake"
  )
  include(LLVMRuntimes)
  return ()
endif()

as a convinience wrapper for just building a single runtime that keeps the differences between the build modes manageable.

@zjlcd
Copy link
Author

zjlcd commented Nov 22, 2025

So far, I have had no intention of introducing too many so-called 'build modes' that would increase the maintenance cost of the CMake files. The runtime-default build mode of the flang-rt project already works well. Just like the compiler-rt project, all the build modes I have verified are described below:

The first build method I learned about is the one described on the homepage(https://compiler-rt.llvm.org/). This might be what you refer to as the 'Standalone mode' in the 'build modes' (if not, please clarify directly). I can show you the script I use, which still works well on the current main branch (although it requires the GCC15 compiler).

#!/usr/bin/bash
work_dir=`pwd`
install_dir=$work_dir/install
ROOTDIR=$work_dir/llvm-project
GCC15_DIR=/home/panda/x86-toolchain/gcc-15.1
export PATH=/home/panda/x86-toolchain/gcc-15.1/bin:$PATH
export LD_LIBRARY_PATH=/home/panda/x86-toolchain/gcc-15.1/lib:$LD_LIBRARY_PATH

cd $work_dir
cd llvm-project
rm -rf build-compiler-rt
mkdir build-compiler-rt
cd build-compiler-rt
cmake -G "Unix Makefiles" \
      -DLLVM_CMAKE_DIR=$ROOTDIR/build \
      -DLLVM_TARGET_TRIPLE="x86_64-unknown-linux-gnu" \
      -DCMAKE_INSTALL_PREFIX=$install_dir \
      -DCMAKE_C_COMPILER=$GCC15_DIR/bin/gcc \
      -DCMAKE_CXX_COMPILER=$GCC15_DIR/bin/g++ \
      ../compiler-rt

make -j16
make install

Secondly, there is the method of using the -DLLVM_ENABLE_PROJECTS=compiler-rt option, which is also the build method I have seen most commonly. As you mentioned, the compiler-rt project is going to deprecate this method.

Lastly, using -DLLVM_ENABLE_RUNTIMES=compiler-rt. which seems to be what the compiler-rt community is trying to use for building this project.

Back to the flang-rt project, the runtime-default build mode works smoothly. but it seems that the project "Standalone build" can easily got some trouble.

I even think that these two build mode(runtime-default and standalone), will not add any extra maintenance costs. otherwise, the compiler-rt community would likely only allowed the runtime-default build mode(There may be other reasons).

I mean no offense. simply regarding the project itself, it is very regrettable if an error is found but no corrections are made.

I'm also very interested in the method you mentioned, and I will give it a try.

Please forgive me if I have offended you in any way.
Thanks again.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants