-3

I get a linkage error 'LINK2019: unresolved external symbol' of the DCompositionCreateDevice function from dcomp.h header, which I believe is a part of Windows SDK and must be reachable out-of-box. Just trivial using of this function leads to the error:

#include <dcomp.h>
int main()
{
DCompositionCreateDevice(nullptr, IID{}, nullptr);
}

The path is C:\Program Files (x86)\Windows Kits\10. Version is 10.0.22621.0 As I checked, in every directory below there is a dcomp.lib file:

Lib\10.0.22621.0\um\arm;

Lib\10.0.22621.0\um\arm64;

Lib\10.0.22621.0\um\x64 (mine, checked the others just in case);

Lib\10.0.22621.0\um\x86;

I thought, maybe I invoked it in the wrong manner, but I can't build my Qt project either (obtained from Conancenter as qt/6.5.1) - a single construction of QApplication in the main leads to the same error.

I updated the version of SDK via the VS Installer from 10.0.20348.0 for Windows 10 to 10.0.22621.0 for Windows 11 - nothing changed. As I continued my attempts, it turned out that all other functions that I tried to invoke from that header led to the same error. Invoking functions from other headers of SDK, including Windows.h, built successfully.

I'm trying to build the project with CMake and MSVC v.143 for x64 and VSCode. Building in VS with .sln files has the same effect.

P.S.: It never led to errors and essentially doesn't make sense to me, but CMake shows this line when configuring

-- Selecting Windows SDK version 10.0.22621.0 to target Windows 10.0.19045.

but I don't have 10.0.19045 version. I don't know, just notice, maybe it can be related to the problem.

UPD: Apparently, the problem was in my misconception about linking to Windows SDK parts. Like it's said in the comments, I just should've used explicit linkage.

Sirzhatina
  • 5
  • 3
  • 2
    Are you linking against `Dcomp.lib` - I know you found the file, but is it in the list of libraries to be linked ? – Richard Critten Aug 10 '23 at 14:28
  • 1
    ^ check the requirements section of the documentation: [https://learn.microsoft.com/en-us/windows/win32/api/dcomp/nf-dcomp-dcompositioncreatedevice#requirements](https://learn.microsoft.com/en-us/windows/win32/api/dcomp/nf-dcomp-dcompositioncreatedevice#requirements) – drescherjm Aug 10 '23 at 14:33
  • @RichardCritten explicit linkage works well, the code's been built. I hope explicit linking with parts of Windows SDK is not solution. The compiler doesn't require its include paths – Sirzhatina Aug 10 '23 at 18:40
  • @drescherjm requirements are met except .dll. There's no dll libraries at all there. Must they be? – Sirzhatina Aug 10 '23 at 18:42
  • 1
    Explicit linkage _is_ the solution. – Jabberwocky Aug 10 '23 at 19:25
  • 1
    _"...I hope explicit linking with parts of Windows SDK ..."_ well you are using the Windows SDK so linking against is required. However `Dcomp.lib` is a stub library which fixes up the calls (eg `DCompositionCreateDevice( ... )`) to `Dcomp.dll` – Richard Critten Aug 10 '23 at 21:09
  • @Jabberwocky ok, let's say explicit linkage is required here. Then two questions: first of all, do I really have to link to this .lib when building Qt app? I never faced problems like that before with building Qt. Second, if I need to give the path to the linker explicitly, why does the compiler not require include paths? Looks weird a little. Thank you for your help – Sirzhatina Aug 11 '23 at 07:06
  • ***Then two questions: first of all, do I really have to link to this .lib when building Qt app?*** Yes if you are using `DCompositionCreateDevice` you will have to link to this `.lib` regardless if you are using the Qt framework or MFC or some other GUI. – drescherjm Aug 11 '23 at 18:19
  • ***Second, if I need to give the path to the linker explicitly*** I would not expect you to need to give the full path since this lib should be in a system location that should already be in the search path while linking. You will still need to add the link to `Dcomp.lib` however as this is not a part of the windows api that will be automatically linked for you. – drescherjm Aug 11 '23 at 18:20
  • ***why does the compiler not require include paths?*** Linking to libraries and including headers are completely separate. – drescherjm Aug 11 '23 at 18:21
  • @drescherjm thank you for your detailed answer. It still looks weird, because, although they are different mechanisms, they work side-by-side resolving dependency as a whole and I often do exactly this way: add an include path for headers and then add a library to link to. Here, we have implicit including paths but explicit linking. Anyway, I'll take it into account. Thank you so much for explanation. UPD: and what looks weird as well is that Qt called from Conan can resolve all dependencies it needs but not this one. – Sirzhatina Aug 11 '23 at 20:06
  • If you are using Conan which means CMake I suspect the bug is in the CMakeLists.txt for the library. It's missing something like `target_link_libraries(sometargetname PUBLIC Dcomp.lib)` – drescherjm Aug 11 '23 at 22:57

0 Answers0