[CMake] cross g++ linking shared instead of static libgcc

Hendrik Sattler post at hendrik-sattler.de
Thu Jan 13 01:19:09 EST 2011


Am Donnerstag, 13. Januar 2011, 02:10:12 schrieb Darren Hollenbeck:
> I am using CMake to cross compile with an arm toolchain and getting a
> linker error:
> undefined reference to `__sync_fetch_and_add_4'
> 
> the toolchain has both a shared and static libgcc:
> ./lib/gcc/arm-linux-gnueabi/4.5.2/libgcc.a
> ./lib/gcc/arm-linux-gnueabi/4.5.2/libgcc_eh.a
> ./arm-linux-gnueabi/lib/libgcc_s.so.1
> ./arm-linux-gnueabi/lib/libgcc_s.so
> 
> the path for both is in the linker directories (from CMakeCXXCompiler.cmake
> generated in the build directory/CMakeFiles), but the path for the static
> is first:
> SET(CMAKE_CXX_IMPLICIT_LINK_DIRECTORIES
> "/opt/gatecraft/arm/lib/gcc/arm-linux-gnueabi/4.5.2;/opt/gatecraft/arm/arm-
> linux-gnueabi/lib;/opt/gatecraft/arm/arm-linux-gnueabi/usr/lib")

Does this matter? No, the libraries have differen names!

> The libraries are not the same, the .so does not have the symbol the linker
> is complaining about but the .a does (I inspected this with nm). What I
> can't figure out is why I can switch the CMAKE_CXX_COMPILER defined in my
> toolchain file to another toolchain (with the same shared/static and linker
> path order) - keeping everything else the same - and the build succeeds. I
> can't find any significant difference in anything in the build directory
> between the two, yet one will link libgcc.a (and therefore works) and the
> other won't (and gives the error above).
> 
> I found that I have a work-around by forcing -static-libgcc in the linker
> flags, but this doesn't explain why it works without this change when I
> switch the compiler to the other toolchain.
> 
> 
> Anyone able to explain the discrepancy here and offer a fix?

You probably have different defaults (by gcc configure flags) for code 
generation. Anyway, this is a problem either with gcc itself, how you 
configured it or a problem with use a atomic operations in your code.
Totally unrelated to cmake.

HS


More information about the CMake mailing list