# How to link an imported shared library to an executable without hard-coding the path and file name?

**URL:** https://discourse.cmake.org/t/how-to-link-an-imported-shared-library-to-an-executable-without-hard-coding-the-path-and-file-name/2067
**Category:** Code
**Created:** [October 25, 2020, 6:28am UTC](https://discourse.cmake.org/t/how-to-link-an-imported-shared-library-to-an-executable-without-hard-coding-the-path-and-file-name/2067 "2020-10-25T06:28:23Z")
**Posts on this page:** 7
**Page:** 1

<div class="post-metadata">

### Author: ![Shane\_Dev](https://discourse.cmake.org/user_avatar/discourse.cmake.org/shane_dev/32/841_2.png) [@Shane\_Dev](https://discourse.cmake.org/u/Shane_Dev)
#### Post date: [October 25, 2020, 6:28am UTC](https://discourse.cmake.org/t/how-to-link-an-imported-shared-library-to-an-executable-without-hard-coding-the-path-and-file-name/2067/1 "2020-10-25T06:28:23Z")

</div>

Hello,

My [CMake project](https://github.com/shanemcandrewai/aten_libtorch/blob/master/CMakeLists.txt) uses some third party libraries which I declared as `IMPORTED` then I set the `IMPORTED_IMPLIB` or `IMPORTED_LOCATION` properties (depending on compiler and type of library) to the full path and file name. I declared the libraries `IMPORTED` because the [libraries’ own build system](https://github.com/pytorch/pytorch/blob/master/tools/build_libtorch.py) consists of a complex mix of Python, CMake and macros which I found difficult to integrate into my own project. Here are key lines of code extracted from my script.

```
add_executable(aten_libtorch aten_min.cpp)
add_library(torch SHARED IMPORTED)
# The next line hard-codes the library path and file name in the executable
set_target_properties(torch PROPERTIES IMPORTED_LOCATION ${ATEN_LIB_DIR}/shared/libtorch_cpu.so)
target_link_libraries(aten_libtorch torch c10)

```

Is the code above standard practice for imported libraries?  
The disadvantage is that when I move the library, for example `libtorch_cpu.so` on Linux, to another location, I then have to amend the script. Instead, I wanted to provide the plain library name, such as `torch_cpu` and a list of relative directories to search. Is this possible?

---

<div class="post-metadata">

### Author: ![McMartin](https://discourse.cmake.org/user_avatar/discourse.cmake.org/mcmartin/32/150_2.png) [@McMartin](https://discourse.cmake.org/u/McMartin)
#### Post date: [October 25, 2020, 9:06am UTC](https://discourse.cmake.org/t/how-to-link-an-imported-shared-library-to-an-executable-without-hard-coding-the-path-and-file-name/2067/2 "2020-10-25T09:06:02Z")

</div>

Why not use the C++ distribution of PyTorch directly? See [https://pytorch.org/cppdocs/installing.html](https://pytorch.org/cppdocs/installing.html) for an example.

---

<div class="post-metadata">

### Author: ![scivision](https://discourse.cmake.org/letter_avatar_proxy/v4/letter/s/a87d85/32.png) [@scivision](https://discourse.cmake.org/u/scivision)
#### Post date: [October 25, 2020, 12:35pm UTC](https://discourse.cmake.org/t/how-to-link-an-imported-shared-library-to-an-executable-without-hard-coding-the-path-and-file-name/2067/3 "2020-10-25T12:35:49Z")

</div>

A generic way I handle this kind of situation is to use find\_library with platform-specific PATHS and PATH\_SUFFIXES.

For the toughest cases where I can’t use find\_library, I use foreach and if(EXISTS) and build filenames with CMAKE\_STATIC\_LIBRARY\_SUFFIX and similar.

---

<div class="post-metadata">

### Author: ![Shane\_Dev](https://discourse.cmake.org/user_avatar/discourse.cmake.org/shane_dev/32/841_2.png) [@Shane\_Dev](https://discourse.cmake.org/u/Shane_Dev)
#### Post date: [October 25, 2020, 12:43pm UTC](https://discourse.cmake.org/t/how-to-link-an-imported-shared-library-to-an-executable-without-hard-coding-the-path-and-file-name/2067/4 "2020-10-25T12:43:07Z")

</div>

because I find building libraries with debug symbols is a useful way to learn them. In addition, I want to learn CMake.

---

<div class="post-metadata">

### Author: ![scivision](https://discourse.cmake.org/letter_avatar_proxy/v4/letter/s/a87d85/32.png) [@scivision](https://discourse.cmake.org/u/scivision)
#### Post date: [October 25, 2020, 12:45pm UTC](https://discourse.cmake.org/t/how-to-link-an-imported-shared-library-to-an-executable-without-hard-coding-the-path-and-file-name/2067/5 "2020-10-25T12:45:23Z")

</div>

In my opinion this is a useful technique to know. I run into projects where their own pkg-config .pc and Cmake scripts are not completely correct on all platforms so I use this technique for workaround

---

<div class="post-metadata">

### Author: ![Shane\_Dev](https://discourse.cmake.org/user_avatar/discourse.cmake.org/shane_dev/32/841_2.png) [@Shane\_Dev](https://discourse.cmake.org/u/Shane_Dev)
#### Post date: [October 25, 2020, 1:59pm UTC](https://discourse.cmake.org/t/how-to-link-an-imported-shared-library-to-an-executable-without-hard-coding-the-path-and-file-name/2067/6 "2020-10-25T13:59:55Z")

</div>

I was hoping to write one single CMake script which could build my project on all supported compilers / platforms / built types without having to code any specific compiler / platform / built type logic with `if(MSVC) ..` or `if(UNIX)..` etc. Is this an unrealistic expectation?

---

<div class="post-metadata">

### Author: ![scivision](https://discourse.cmake.org/letter_avatar_proxy/v4/letter/s/a87d85/32.png) [@scivision](https://discourse.cmake.org/u/scivision)
#### Post date: [October 26, 2020, 8:05am UTC](https://discourse.cmake.org/t/how-to-link-an-imported-shared-library-to-an-executable-without-hard-coding-the-path-and-file-name/2067/7 "2020-10-26T08:05:50Z")

</div>

Yes that’s how I do it. If() statement feeding above techniques
