Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: Failed linking with GetOpenFileName (Read 379 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Failed linking with GetOpenFileName

Hi.
Maybe someone had this problem or could point me to its root...
Trying to call GetOpenFileName() method from Windows SDK (comdlg32.h), but during linking it fails with the following:

Code: [Select]
mainmenu.obj : error LNK2001: unresolved external symbol __imp_GetOpenFileNameW
SDK-2023-09-23\foobar2000\foo_sample\x64\Release\foo_sample.dll : fatal error LNK1120: 1 unresolved externals

I just included this minimal chunk to the mainmenu.cpp of the foo_sample project from the SDK-2023-09-23, in the execute() method.

Code: [Select]
OPENFILENAME ofn;
GetOpenFileName(&ofn);

I found that the method should be in the comdlg.lib of the Windows SDK 10. I tried with 10.0.20348.0 which should have the method, according to this:
https://learn.microsoft.com/en-us/windows/win32/api/commdlg/nf-commdlg-getopenfilenamew

Checked in the project properties that it points to that version.
And the .lib is there of course.
The verbose build log also contains the path to the directory with the .lib, although it's huge and I'm not exactly sure where to look.
I can attach the full log if someone needs it, but it should be reproducible on another PC I think.

Weird thing is that I found GetOpenFileName in the shared library in the foobar SDK, and it builds.

Also, when I build a minimal console app in Visual Studio with that chunk, plus include <windows.h>, it build without errors (in exe and dll modes).

Thanks.

Re: Failed linking with GetOpenFileName

Reply #2 –
Indeed, just ignored that direct solution, as was overhelmed thinking it wasn't finding the correct win SDK path.
For comparison tried an old foobar SDK, from 2015 and that built right away, cause the project had all the libs included explicitly:
Code: [Select]
../shared/shared.lib;kernel32.lib;user32.lib;gdi32.lib;winspool.lib;comdlg32.lib;advapi32.lib;shell32.lib;ole32.lib;oleaut32.lib;uuid.lib;odbc32.lib;odbccp32.lib;%(AdditionalDependencies)

Thanks a lot for pointing me to the right direction )