# Avoid false positives from check\_symbol\_exists()

**URL:** https://discourse.cmake.org/t/avoid-false-positives-from-check-symbol-exists/4133
**Category:** Code
**Created:** [September 22, 2021, 9:31am UTC](https://discourse.cmake.org/t/avoid-false-positives-from-check-symbol-exists/4133 "2021-09-22T09:31:33Z")
**Posts on this page:** 6
**Page:** 1

<div class="post-metadata">

### Author: ![eriols](https://discourse.cmake.org/user_avatar/discourse.cmake.org/eriols/32/945_2.png) [@eriols](https://discourse.cmake.org/u/eriols)
#### Post date: [September 22, 2021, 9:31am UTC](https://discourse.cmake.org/t/avoid-false-positives-from-check-symbol-exists/4133/1 "2021-09-22T09:31:33Z")

</div>

When cross-compiling what’s a good practice for using `check_symbol_exists` against only the toolchain, that is avoiding that it finds the symbol on the host system as a false positive?  
To elaborate, today we do those checks in the main file so they can also be made when you are not cross-compiling, so I guess that would mean 1) do the check in the toolchain file and then 2) avoid doing it in the main file if `CMAKE_CROSSCOMPILING` is set? Any better suggestions?

---

<div class="post-metadata">

### Author: ![ben.boeckel](https://discourse.cmake.org/letter_avatar_proxy/v4/letter/b/ea5d25/32.png) [@ben.boeckel](https://discourse.cmake.org/u/ben.boeckel)
#### Post date: [September 22, 2021, 7:23pm UTC](https://discourse.cmake.org/t/avoid-false-positives-from-check-symbol-exists/4133/2 "2021-09-22T19:23:22Z")

</div>

Why would it be any different? If the compiler is a cross-compiler, it shouldn’t be targeting the host, so why would it interfere if the toolchain is properly configured?

---

<div class="post-metadata">

### Author: ![eriols](https://discourse.cmake.org/user_avatar/discourse.cmake.org/eriols/32/945_2.png) [@eriols](https://discourse.cmake.org/u/eriols)
#### Post date: [September 22, 2021, 8:16pm UTC](https://discourse.cmake.org/t/avoid-false-positives-from-check-symbol-exists/4133/3 "2021-09-22T20:16:21Z")

</div>

Thank you.  
I guess the toolchain is thus not properly configured as the host symbols seems to leak over. What is the easiest way to avoid that? Setting CMAKE\_SYSROOT?

---

<div class="post-metadata">

### Author: ![ben.boeckel](https://discourse.cmake.org/letter_avatar_proxy/v4/letter/b/ea5d25/32.png) [@ben.boeckel](https://discourse.cmake.org/u/ben.boeckel)
#### Post date: [September 22, 2021, 8:22pm UTC](https://discourse.cmake.org/t/avoid-false-positives-from-check-symbol-exists/4133/4 "2021-09-22T20:22:49Z")

</div>

I’m not completely sure as I don’t do cross-compiles that much myself (and when I have done it, it hasn’t been in a case where the target and host libraries would even link due to arch/platform differences to give a bogus answer here).

---

<div class="post-metadata">

### Author: ![jtxa](https://discourse.cmake.org/user_avatar/discourse.cmake.org/jtxa/32/1535_2.png) [@jtxa](https://discourse.cmake.org/u/jtxa)
#### Post date: [September 23, 2021, 10:37pm UTC](https://discourse.cmake.org/t/avoid-false-positives-from-check-symbol-exists/4133/5 "2021-09-23T22:37:24Z")

</div>

Have you checked the settings mentioned in the chapter “[Cross Compiling for Linux](https://cmake.org/cmake/help/latest/manual/cmake-toolchains.7.html#id13)” (mainly the `CMAKE_FIND_ROOT_PATH_MODE_*` ones).

---

<div class="post-metadata">

### Author: ![eriols](https://discourse.cmake.org/user_avatar/discourse.cmake.org/eriols/32/945_2.png) [@eriols](https://discourse.cmake.org/u/eriols)
#### Post date: [September 24, 2021, 9:27am UTC](https://discourse.cmake.org/t/avoid-false-positives-from-check-symbol-exists/4133/6 "2021-09-24T09:27:29Z")

</div>

This is a bit embarrassing but I think the issue is that I have instances were the supplied toolchain is incomplete and we therefore build with a similar more generic one that might have symbols the original supplier does not expect. The toolchain in itself is probably setup correct, but if you use toolchain B instead of toolchain A of course you’re asking for trouble.  
So in terms of cmake it’s probably all good, just a suboptimal process around it.  
Sorry for the unnecessary question!
