# Potential Bug in 'cmake/Modules/Compiler/clang.cmake' (CMAKE\_C(XX)\_COMPILE\_OPTIONS\_PIC)

**URL:** https://discourse.cmake.org/t/potential-bug-in-cmake-modules-compiler-clang-cmake-cmake-c-xx-compile-options-pic/1933
**Category:** Development
**Tags:** comp:clang
**Created:** [September 28, 2020, 9:59pm UTC](https://discourse.cmake.org/t/potential-bug-in-cmake-modules-compiler-clang-cmake-cmake-c-xx-compile-options-pic/1933 "2020-09-28T21:59:31Z")
**Posts on this page:** 7
**Page:** 1

<div class="post-metadata">

### Author: ![marchani](https://discourse.cmake.org/user_avatar/discourse.cmake.org/marchani/32/857_2.png) [@marchani](https://discourse.cmake.org/u/marchani)
#### Post date: [September 28, 2020, 9:59pm UTC](https://discourse.cmake.org/t/potential-bug-in-cmake-modules-compiler-clang-cmake-cmake-c-xx-compile-options-pic/1933/1 "2020-09-28T21:59:31Z")

</div>

I was attempting to cross-compile gRPC ([https://github.com/grpc/grpc](https://github.com/grpc/grpc)) from Windows to Linux as a third-party dependency using CMake and the Clang compiler; however, I encountered what I _believe_ may be incorrect behavior in CMake:

- When attempting this cross-compilation, my project (executable) was unable to link to the static libraries in gRPC. The reported error was something to the following effect: “relocation R\_X86\_64\_32S against `\*\*\*’ can not be used when making a shared object; recompile with -fPIC”.

- I initially suspected the CMAKE\_POSITION\_INDEPENDENT\_CODE variable was not being set correctly; however, I confirmed the CMAKE\_POSITION\_INDEPENDENT\_CODE had the correct value of ‘ON’.

- Upon further investigation, I noticed that when using the Clang compiler, the CMAKE\_C(XX)\_COMPILE\_OPTIONS\_PIC variables do not get set to ‘-fPIC’ in cmake/Modules/Compiler/clang.cmake; however, this same variable is set to ‘-fPIC’ in cmake/Modules/Compiler/GNU.cmake.

- This difference in behavior explains why I saw the linker error reported above. It also explains why this cross-compilation fails when using Clang, but is successful when using the GNU compiler.

Is this difference in behavior for the CMAKE\_C(XX)\_COMPILE\_OPTIONS\_PIC variables when using the GNU and Clang compilers expected? In case it helps, this issue is similar to the one addressed by the following merge request: [https://gitlab.kitware.com/cmake/cmake/-/merge\_requests/1692/diffs](https://gitlab.kitware.com/cmake/cmake/-/merge_requests/1692/diffs).

---

<div class="post-metadata">

### Author: ![brad.king](https://discourse.cmake.org/user_avatar/discourse.cmake.org/brad.king/32/11_2.png) [@brad.king](https://discourse.cmake.org/u/brad.king)
#### Post date: [September 29, 2020, 9:11am UTC](https://discourse.cmake.org/t/potential-bug-in-cmake-modules-compiler-clang-cmake-cmake-c-xx-compile-options-pic/1933/2 "2020-09-29T09:11:28Z")

</div>

The Clang settings re-use the GNU settings [here](https://gitlab.kitware.com/cmake/cmake/-/blob/v3.18.3/Modules/Compiler/Clang.cmake#L27), and that should get the PIC option from [here](https://gitlab.kitware.com/cmake/cmake/-/blob/v3.18.3/Modules/Compiler/GNU.cmake#L22). You could run `cmake . --trace-expand 2>log` in your build tree and look at the `log` file to see the verbose trace of execution. That will show whether the flag variable is set.

---

<div class="post-metadata">

### Author: ![marchani](https://discourse.cmake.org/user_avatar/discourse.cmake.org/marchani/32/857_2.png) [@marchani](https://discourse.cmake.org/u/marchani)
#### Post date: [September 29, 2020, 2:06pm UTC](https://discourse.cmake.org/t/potential-bug-in-cmake-modules-compiler-clang-cmake-cmake-c-xx-compile-options-pic/1933/3 "2020-09-29T14:06:09Z")

</div>

Thank you for the quick response.

I performed the steps you outlined to generate the `log` file using the Clang compiler. After reviewing the `log` file, I can confirm the following:

- The `CMAKE_C_COMPILE_OPTIONS_PIC` flag variable _is not_ set
- Line 102 of `CMakeCXXInformation.cmake` sets `CMAKE_CXX_COMPILE_OPTIONS_PIC` to “” (since `CMAKE_C_COMPILE_OPTIONS_PIC` was not set).

I also tried the following steps to further narrow down the issue:

- If I manually set `CMAKE_C_COMPILE_OPTIONS_PIC` to `-fPIC` in my project’s `CMakeLists.txt` file, then I can successfully compile and link to the third-party libraries. The log file also confirms that if I manually set `CMAKE_C_COMPILE_OPTIONS_PIC` to `-fPIC`, then `CMAKE_CXX_COMPILE_OPTIONS_PIC` is set to `-fPIC`. This is the temporary workaround that I have implemented.

- If I change the compiler from Clang to GNU compiler, the log file confirms that `CMAKE_C_COMPILE_OPTIONS_PIC` is set to `-fPIC` (by line 22 of `GNU.cmake`). In other words, I do not have to manually set this flag variable in my project’s `CMakeLists.txt` file and it appears to be different behavior compared to when I use the Clang compiler.

In case it helps, here are the values of other flag variables in the resulting `CMakeCCompiler.cmake` file when using the Clang compiler that may impact this behavior:

- `CMAKE_C_PLATFORM_ID` is set to “Windows” (this is set to “MinGW” when using GNU compiler)
- `CMAKE_C_SIMULATE_ID` is set to “MSVC” (this is set to “” when using GNU compiler)

Does this information help to narrow down whether I am not using CMake correctly? My suspicion is that `__compiler_gnu(${lang})` is not getting called in `Clang.cmake` because `CMAKE_C_SIMULATE_ID` equals `MSVC`.

Is it possible that `Clang-DetermineCompilerInternal.cmake` is setting `CMAKE_C_SIMULATE_ID` to `MSVC` if Clang is defining the `_MSC_VER` macro by default on Windows (even though `CMAKE_C_COMPILER_FRONTEND_VARIANT` is `GNU`): [http://clang.llvm.org/docs/UsersManual.html#microsoft-extensions](http://clang.llvm.org/docs/UsersManual.html#microsoft-extensions)?

Please let me know if you need any additional information from me.

---

<div class="post-metadata">

### Author: ![brad.king](https://discourse.cmake.org/user_avatar/discourse.cmake.org/brad.king/32/11_2.png) [@brad.king](https://discourse.cmake.org/u/brad.king)
#### Post date: [September 30, 2020, 11:31am UTC](https://discourse.cmake.org/t/potential-bug-in-cmake-modules-compiler-clang-cmake-cmake-c-xx-compile-options-pic/1933/4 "2020-09-30T11:31:28Z")

</div>

If `CMAKE_C_SIMULATE_ID` is `MSVC` and `CMAKE_C_COMPILER_FRONTEND_VARIANT` is `GNU`, that means it thinks you’re targeting Windows and not Linux. Please post your toolchain file. Is it setting `CMAKE_C_COMPILER_TARGET` to an appropriate Clang triple?

---

<div class="post-metadata">

### Author: ![marchani](https://discourse.cmake.org/user_avatar/discourse.cmake.org/marchani/32/857_2.png) [@marchani](https://discourse.cmake.org/u/marchani)
#### Post date: [September 30, 2020, 12:26pm UTC](https://discourse.cmake.org/t/potential-bug-in-cmake-modules-compiler-clang-cmake-cmake-c-xx-compile-options-pic/1933/5 "2020-09-30T12:26:47Z")

</div>

Here is the toolchain file:

> set(CMAKE\_SYSTEM\_NAME Linux)  
> set(CMAKE\_SYSTEM\_PROCESSOR x86\_64)
> 
> set(triple x86\_64-unknown-linux-gnu)
> 
> set(toolchain C:/v15\_clang-8.0.1-centos7/${triple})
> 
> set(CMAKE\_SYSROOT ${toolchain})
> 
> set(CMAKE\_C\_COMPILER ${toolchain}/bin/clang.exe)  
> set(CMAKE\_C\_COMPILER\_TARGET ${triple})
> 
> set(CMAKE\_CXX\_COMPILER ${toolchain}/bin/clang++.exe)  
> set(CMAKE\_CXX\_COMPILER\_TARGET ${triple})
> 
> set(CMAKE\_BUILD\_WITH\_INSTALL\_RPATH ON)
> 
> set(CMAKE\_FIND\_ROOT\_PATH\_MODE\_PROGRAM NEVER)  
> set(CMAKE\_FIND\_ROOT\_PATH\_MODE\_LIBRARY ONLY)  
> set(CMAKE\_FIND\_ROOT\_PATH\_MODE\_INCLUDE ONLY)  
> set(CMAKE\_FIND\_ROOT\_PATH\_MODE\_PACKAGE ONLY)
> 
> #The following line is a workaround until the following issue is addressed: [Potential Bug in 'cmake/Modules/Compiler/clang.cmake' (CMAKE\_C(XX)\_COMPILE\_OPTIONS\_PIC)](https://discourse.cmake.org/t/potential-bug-in-cmake-modules-compiler-clang-cmake-cmake-c-xx-compile-options-pic/1933)  
> #Once the issue is addressed, we should be able to delete the following line.  
> set(CMAKE\_C\_COMPILE\_OPTIONS\_PIC “-fPIC”)
> 
> add\_compile\_options(–target=${triple} --sysroot=${CMAKE\_SYSROOT})  
> add\_link\_options(-v --target=${triple} --sysroot=${CMAKE\_SYSROOT})  
> add\_compile\_definitions(GRPC\_LINUX\_TCP\_H=1)

As far as I can tell, this toolchain file sets CMAKE\_C\_COMPILER\_TARGET to an appropriate Clang triple (i.e., x86\_64-unknown-linux-gnu) in `set(CMAKE_C_COMPILER_TARGET ${triple})`.

---

<div class="post-metadata">

### Author: ![brad.king](https://discourse.cmake.org/user_avatar/discourse.cmake.org/brad.king/32/11_2.png) [@brad.king](https://discourse.cmake.org/u/brad.king)
#### Post date: [September 30, 2020, 12:38pm UTC](https://discourse.cmake.org/t/potential-bug-in-cmake-modules-compiler-clang-cmake-cmake-c-xx-compile-options-pic/1933/6 "2020-09-30T12:38:49Z")

</div>

Ah, this looks like [CMake Issue 21097](https://gitlab.kitware.com/cmake/cmake/-/issues/21097) which will be fixed in 3.19. You can either build CMake from source using the upstream `master` branch, or try a recent [nightly binary](https://cmake.org/files/dev/?C=M;O=D).

---

<div class="post-metadata">

### Author: ![marchani](https://discourse.cmake.org/user_avatar/discourse.cmake.org/marchani/32/857_2.png) [@marchani](https://discourse.cmake.org/u/marchani)
#### Post date: [September 30, 2020, 1:32pm UTC](https://discourse.cmake.org/t/potential-bug-in-cmake-modules-compiler-clang-cmake-cmake-c-xx-compile-options-pic/1933/7 "2020-09-30T13:32:31Z")

</div>

I tested the following binary and it looks like the issue is resolved: cmake-3.18.20200929-g365b5dc-win64-x64. Now, when I read the value of `CMAKE_C_COMPILE_OPTIONS_PIC`, it is set to “-fPIC”, as expected, and I am able to link successfully to the third-party libraries without having to manually set this flag variable in my toolchain file.

Thank you for the outstanding support.
