# CMake Duplicating Debug Library and not including normal library
**URL:** https://discourse.cmake.org/t/cmake-duplicating-debug-library-and-not-including-normal-library/1174
**Category:** Usage
**Tags:** os:windows, gen:vs
**Created:** [May 8, 2020, 10:11pm UTC](https://discourse.cmake.org/t/cmake-duplicating-debug-library-and-not-including-normal-library/1174 "2020-05-08T22:11:40Z")
**Posts on this page:** 8
**Page:** 1
### Author:  [@jasperswallen](https://discourse.cmake.org/u/jasperswallen)
#### Post date: [May 8, 2020, 10:11pm UTC](https://discourse.cmake.org/t/cmake-duplicating-debug-library-and-not-including-normal-library/1174/1 "2020-05-08T22:11:41Z")
Hi! I’m experiencing some strange behavior with CMake’s Visual Studio makefile generator.
I have a project that includes Python3’s libraries through the [normal methods](https://cmake.org/cmake/help/v3.17/module/FindPython3.html), and it successfully finds both the debug and normal version of the libraries (`optimized;C:/Program Files/Python38/libs/python38.lib;debug;C:/Program Files/Python38/libs/python38_d.lib`)
However, when I run cmake with the VS (16 2019) generator, in the additional dependencies section, `C:/Program Files/Python38/libs/python38_d.lib` is included twice and `C:/Program Files/Python38/libs/python38.lib` is never included.
This results in [this LNK1104 linker error](https://stackoverflow.com/questions/61311349/link-fatal-error-lnk1104-cannot-open-file-python38-lib-with-cmake-finding-l/61321941#61321941). If I manually change one of the `_d`'s to the optimized version, it compiles fine, so it’s not a back-breaking issue but it is rather inconvenient.
---
### Author:  [@craig.scott](https://discourse.cmake.org/u/craig.scott)
#### Post date: [May 9, 2020, 12:34am UTC](https://discourse.cmake.org/t/cmake-duplicating-debug-library-and-not-including-normal-library/1174/2 "2020-05-09T00:34:55Z")
@marc.chevrier Any idea what might be happening here?
---
### Author:  [@marc.chevrier](https://discourse.cmake.org/u/marc.chevrier)
#### Post date: [May 9, 2020, 9:32am UTC](https://discourse.cmake.org/t/cmake-duplicating-debug-library-and-not-including-normal-library/1174/3 "2020-05-09T09:32:14Z")
From the `stackoverflow` description, I think the problem comes from the mix of `Boost.Python3` and `Python3` libraries…
I don’t have `boost` installed, so I cannot validate my hypothesis but if I specify twice `python` libraries, in the `vcxproj`, there is a double dependency which is not quite optimal even if debug and release modes are correctly handled (double debug library for debug mode and double release library for release modes).
---
### Author:  [@jasperswallen](https://discourse.cmake.org/u/jasperswallen)
#### Post date: [May 9, 2020, 10:13pm UTC](https://discourse.cmake.org/t/cmake-duplicating-debug-library-and-not-including-normal-library/1174/4 "2020-05-09T22:13:15Z")
I don’t think the issue has anything to do with Boost. I commented out all the lines with Boost and I still have the debug library included twice and the normal library not included at all.
---
### Author:  [@marc.chevrier](https://discourse.cmake.org/u/marc.chevrier)
#### Post date: [May 10, 2020, 7:43am UTC](https://discourse.cmake.org/t/cmake-duplicating-debug-library-and-not-including-normal-library/1174/5 "2020-05-10T07:43:25Z")
Definitively, I don’t understand what is exactly your problem.
Let me explain the expected behavior regarding keywords `debug` and `optimized` for libraries:
- For debug builds (CMAKE\_BUILD\_TYPE=Debug for mono config generators or debug type for multi configs generators (`Visual Studio` in your case)), the library specified after `debug` keyword is selected **and only** this library.
- For release builds (CMAKE\_BUILD\_TYPE=Release or RelWithDebInfo, etc… for mono config generators or release type for multi configs generators (`Visual Studio` in your case)), the library specified after `optimized` keyword is selected **and only** this library.
So, in the `.vcxproj` file, under `Debug` section, it is absolutely normal that optimized build is not included. Now for the duplication of `python38_d.lib` value, it is due to the fact that the library is specified multiple times in your `CMake` files.
---
### Author:  [@jasperswallen](https://discourse.cmake.org/u/jasperswallen)
#### Post date: [May 10, 2020, 6:41pm UTC](https://discourse.cmake.org/t/cmake-duplicating-debug-library-and-not-including-normal-library/1174/6 "2020-05-10T18:41:41Z")
Sure, I get that the debug library should be the one included for the debug build. However, when I try to build with MSBuild.exe, it fails to link because it’s trying to link with the non-debug version. “Correcting” it in the `.vcxproj` just gives it the non-debug library to link against, but in reality it should never even be _trying_ to link against the non-debug library.
---
### Author:  [@marc.chevrier](https://discourse.cmake.org/u/marc.chevrier)
#### Post date: [May 10, 2020, 9:48pm UTC](https://discourse.cmake.org/t/cmake-duplicating-debug-library-and-not-including-normal-library/1174/7 "2020-05-10T21:48:43Z")
This means you have, in your project, a dependency on some code compiled in release mode against Python API. The `Python` API use `#pragma comment(lib,...)` declarations to force link of debug or release library…
---
### Author:  [@ben.boeckel](https://discourse.cmake.org/u/ben.boeckel)
#### Post date: [May 11, 2020, 4:41pm UTC](https://discourse.cmake.org/t/cmake-duplicating-debug-library-and-not-including-normal-library/1174/8 "2020-05-11T16:41:48Z")
> [@marc.chevrier](#):
>
> The `Python` API use `#pragma comment(lib,...)` declarations to force link of debug or release library…
Python 3.9 will have a mechanism to disable this behavior. [Issue 38728: Update PC/pyconfig.h to support disabling auto linking - Python tracker](https://bugs.python.org/issue38728)