# target\_link\_libraries is adding -l when I don't want it to
**URL:** https://discourse.cmake.org/t/target-link-libraries-is-adding-l-when-i-dont-want-it-to/7335
**Category:** Usage
**Tags:** os:linux
**Created:** [January 27, 2023, 2:41am UTC](https://discourse.cmake.org/t/target-link-libraries-is-adding-l-when-i-dont-want-it-to/7335 "2023-01-27T02:41:31Z")
**Posts on this page:** 4
**Page:** 1
### Author:  [@Barry\_Revzin](https://discourse.cmake.org/u/Barry_Revzin)
#### Post date: [January 27, 2023, 2:41am UTC](https://discourse.cmake.org/t/target-link-libraries-is-adding-l-when-i-dont-want-it-to/7335/1 "2023-01-27T02:41:32Z")
Sorry I don’t have a short repro for this, but hopefully I can provide enough information to explain the issue.
I have code like this, using cmake 3.21:
```cmake
cmake_policy(SET CMP0060 NEW)
add_custom_command(
OUTPUT
path/to/meow.so
COMMAND
...
)
add_executable(cat cat.cxx)
target_link_libraries(cat PRIVATE path/to/meow.so)
```
Note it’s `meow.so`, not `libmeow.so`.
When I run `ninja cat`, it fails, because it’s trying to link `-lmeow`, which is looking for `libmeow.so`, which is the wrong name of the shared library. `meow.so` _is_ built though and is in the right place.
When I _then_ run `ninja rebuild_cache && ninja cat`, the second time around it does actually link `path/to/meow.so` and everything works as expected.
I had a lot of trouble understanding what the documentation of [`CMP0060`](https://cmake.org/cmake/help/latest/policy/CMP0060.html#policy:CMP0060) means, but I thought it intended this to just work?
Alternatively, if I instead do:
```cmake
add_library(libmeow SHARED IMPORTED)
set_target_properties(libmeow PROPERTIES IMPORTED_LOCATION path/to/meow.so)
target_link_libraries(cat PRIVATE libmeow)
```
then this works on the first go.
Why doesn’t the first version just work?
---
### Author:  [@ben.boeckel](https://discourse.cmake.org/u/ben.boeckel)
#### Post date: [January 27, 2023, 1:29pm UTC](https://discourse.cmake.org/t/target-link-libraries-is-adding-l-when-i-dont-want-it-to/7335/2 "2023-01-27T13:29:03Z")
Strange. I suspect some of it is that sources are where (IIRC) custom command dependencies are looked up, not link libraries. What you should be able to do is something like this though:
```cmake
add_custom_command(OUTPUT path/to/meow.so)
add_custom_target(meow)
add_dependencies(meow DEPENDS path/to/meow.so)
add_library(meow::meow SHARED IMPORTED)
add_dependencies(meow::meow meow)
```
That said, this behavior probably has to do with `meow.so` existing between the first and second configures.
---
### Author:  [@Barry\_Revzin](https://discourse.cmake.org/u/Barry_Revzin)
#### Post date: [January 27, 2023, 3:42pm UTC](https://discourse.cmake.org/t/target-link-libraries-is-adding-l-when-i-dont-want-it-to/7335/3 "2023-01-27T15:42:47Z")
Sorry I don’t follow.
The issue is that instead of just passing `path/to/meow.so` on the command-line, cmake transforms this into `-Lpath/to -lmeow` the first time around (which is an invalid transformation because that’s the wrong name).
The second time around (or with the altered form using the `IMPORTED_LOCATION`), it does correctly just pass `path/to/meow.so`.
It seems like between CMP0003 and CMP0060, cmake _should_ respect the code I’m actually writing, but that appears to not be the case, and I don’t understand between the description of either of the two policies what the actual behavior is supposed to be.
---
### Author:  [@ben.boeckel](https://discourse.cmake.org/u/ben.boeckel)
#### Post date: [January 29, 2023, 1:23pm UTC](https://discourse.cmake.org/t/target-link-libraries-is-adding-l-when-i-dont-want-it-to/7335/4 "2023-01-29T13:23:19Z")
> [@Barry\_Revzin](#):
>
> The issue is that instead of just passing `path/to/meow.so` on the command-line, cmake transforms this into `-Lpath/to -lmeow` the first time around (which is an invalid transformation because that’s the wrong name).
Yes, this sounds like a bug of some sort. Does what I posted above work (as it is the intended workflow today AFAIK)? We should still look into the issue, but I think it can just be avoided here.