# Getting undefined reference error despite of having the library specified in CMake

**URL:** https://discourse.cmake.org/t/getting-undefined-reference-error-despite-of-having-the-library-specified-in-cmake/1888
**Category:** Usage
**Created:** [September 22, 2020, 5:44pm UTC](https://discourse.cmake.org/t/getting-undefined-reference-error-despite-of-having-the-library-specified-in-cmake/1888 "2020-09-22T17:44:25Z")
**Posts on this page:** 1
**Showing post:** 2

<div class="post-metadata">

### Author: ![Coderx7](https://discourse.cmake.org/user_avatar/discourse.cmake.org/coderx7/32/837_2.png) [@Coderx7](https://discourse.cmake.org/u/Coderx7)
#### Post date: [September 23, 2020, 2:50am UTC](https://discourse.cmake.org/t/getting-undefined-reference-error-despite-of-having-the-library-specified-in-cmake/1888/2 "2020-09-23T02:50:25Z")

</div>

## TLDR:

The thrid party lib (torch) was built using a `Pre-cxx11` ABI, and libs built with that couldn’t obviously be linked to the object that was using `cxx11` ABI!

## Long Explanation:

After hours of debugging of a code that worked just fine in windows both in Visual Studio and CMake while being a pain in the neck in linux I found the culprit!  
The libtorch is shipped with two types of build `Pre-cxx11` and `cxx11` ABIs!  
It was using the `Pre-cxx11` built libs that was shipped with its Python package (torch1.6cpu) and since Anaconda3 was in the Path and I was also using it to build the libs I faced this issue.  
What gave it away after all these hours was the weird arguments to the undefined methods which were : `std::__cxx11::basic_string` where it should have been simply `std::string`. I didnt expect this two to be different and thought thats a weird naming scheme the g++ is using until moments ago that made me say, lets give that a search maybe I can get something out it! lo and behold! this was the case :

> If you get linker errors about undefined references to symbols that  
> involve types in the std::\_\_cxx11 namespace or the tag [abi:cxx11]  
> then it probably indicates that you are trying to link together object  
> files that were compiled with different values for the  
> \_GLIBCXX\_USE\_CXX11\_ABI macro. This commonly happens when linking to a third-party library that was compiled with an older version of GCC. If  
> the third-party library cannot be rebuilt with the new ABI then you  
> will need to recompile your code with the old ABI.

[ref](https://stackoverflow.com/questions/33394934/converting-std-cxx11string-to-stdstring)  
To fix this I simply directly used the libtorch cxx11 in all libs creation and that just did it. meaning, unlike what is being shown in the Pytorch’s official documentaion,  
**DO NOT DO:**

```auto
cmake -DCMAKE_PREFIX_PATH="$(python -c 'import torch.utils; print(torch.utils.cmake_prefix_path)')" ..

```

By doing this all hell will break loose if you, like me expected the libs to have been built with `cxx11`! becasue they have not!

Note that this is not the case under windows! so if you are on linux, just grab and use the prebuilt libs with `CXX11` ABI! and avoid what ships with Pytorch!

---

_[View the full topic](https://discourse.cmake.org/t/getting-undefined-reference-error-despite-of-having-the-library-specified-in-cmake/1888)._