[imgui-sfml] include failure

[copyrat90]

Host Environment

• OS: Windows 10 / Ubuntu 20.04
• Compiler: MSVC 19.29.30137(x64) / g++ 9.3

To Reproduce
./vcpkg install imgui-sfml

Small snippet to reproduce the linker error.

#include <SFML/Graphics/RenderWindow.hpp>
#include <imgui-SFML.h>
#include <imgui.h>

int main()
{
    sf::RenderWindow window(sf::VideoMode(640, 480), "Test window");
    ImGui::SFML::Init(window);
    ImGui::SFML::Shutdown();
}

(Also, manifest mode projects give the same errors.)

Failure logs

# MSVC classic mode project
1>------ Build started: Project: ConsoleApplication2, Configuration: Debug x64 ------
1>ConsoleApplication2.cpp
1>ImGui-SFML.lib(imgui-SFML.cpp.obj) : error LNK2019: unresolved external symbol "void __cdecl ImGui::Image(unsigned int,struct ImVec2 const &,struct ImVec2 const &,struct ImVec2 const &,struct ImVec4 const &,struct ImVec4 const &)" (?Image@ImGui@@YAXIAEBUImVec2@@00AEBUImVec4@@1@Z) referenced in function "void __cdecl ImGui::Image(class sf::Texture const &,class sf::Vector2<float> const &,class sf::Color const &,class sf::Color const &)" (?Image@ImGui@@YAXAEBVTexture@sf@@AEBV?$Vector2@M@3@AEBVColor@3@2@Z)
1>ImGui-SFML.lib(imgui-SFML.cpp.obj) : error LNK2019: unresolved external symbol "bool __cdecl ImGui::ImageButton(unsigned int,struct ImVec2 const &,struct ImVec2 const &,struct ImVec2 const &,int,struct ImVec4 const &,struct ImVec4 const &)" (?ImageButton@ImGui@@YA_NIAEBUImVec2@@00HAEBUImVec4@@1@Z) referenced in function "bool __cdecl ImGui::ImageButton(class sf::Texture const &,class sf::Vector2<float> const &,int,class sf::Color const &,class sf::Color const &)" (?ImageButton@ImGui@@YA_NAEBVTexture@sf@@AEBV?$Vector2@M@3@HAEBVColor@3@2@Z)
1>C:\Users\Home\source\repos\ConsoleApplication2\x64\Debug\ConsoleApplication2.exe : fatal error LNK1120: 2 unresolved externals
1>Done building project "ConsoleApplication2.vcxproj" -- FAILED.
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========

Additional context
v2.3 port worked fine, but as soon as I updated vcpkg to use the v2.4 port, this error pops up.
Probably something is broken in the v2.4 port update(#21460)?

[LilyWangLL]

Thanks for your issue, I will test this issue locally.

[caladil]

Seeing the exact same missing symbols on Windows 11 with the Visual Studio 2022 (v143) toolset. imgui-sfml v2.4 and imgui v1.85 are installed via vcpkg.

The only minor difference between the code above and mine is that I'm including imgui.h and imgui-SFML.h before I include SFML/Graphics.hpp.

[JackBoosY]

This issue can be reproduced and I need to check the symbol declarations.

[JackBoosY]

The reason why these symbols are not found is because the definitions of ImTextureID in imgui and imgui-sfml are different.
In imgui, since we use the default configuration, ImTextureID is void* in imgui.h:

#ifndef ImTextureID
typedef void* ImTextureID;          // Default: store a pointer or an integer fitting in a pointer (most renderer backends are ok with that)
#endif

However, in imgui-sfml, it's redefined with unsigned int in imconfig-SFML.h:

#define ImTextureID unsigned int

Therefore, the symbol that imgui-sfml expects to find changes from YA_NPEAXAEBUImVec2@@11HAEBUImVec4@@2@Z to YA_NAEBVTexture@sf@@AEBV?$Vector2@M@3@HAEBVColor@3@2@Z.

Since imgui officially still does not accept cmake buildsystem, the value of ImTextureID should be set according to the current architecture. I think the only way is to add a new feature to imgui to specify this value?
Here is the official comments:

// Important: to compile on 32-bit systems, this backend requires code to be compiled with '#define ImTextureID ImU64'.
// This is because we need ImTextureID to carry a 64-bit value and by default ImTextureID is defined as void*.
// To build this on 32-bit systems:
// - [Solution 1] IDE/msbuild: in "Properties/C++/Preprocessor Definitions" add 'ImTextureID=ImU64' (this is what we do in the 'example_win32_direct12/example_win32_direct12.vcxproj' project file)
// - [Solution 2] IDE/msbuild: in "Properties/C++/Preprocessor Definitions" add 'IMGUI_USER_CONFIG="my_imgui_config.h"' and inside 'my_imgui_config.h' add '#define ImTextureID ImU64' and as many other options as you like.
// - [Solution 3] IDE/msbuild: edit imconfig.h and add '#define ImTextureID ImU64' (prefer solution 2 to create your own config file!)
// - [Solution 4] command-line: add '/D ImTextureID=ImU64' to your cl.exe command-line (this is what we do in the example_win32_direct12/build_win32.bat file)

// You can use unmodified imgui_impl_* files in your project. See examples/ folder for examples of using this.
// Prefer including the entire imgui/ repository into your project (either as a copy or as a submodule), and only build the backends you need.
// If you are new to Dear ImGui, read documentation from the docs/ folder + read the top of imgui.cpp.
// Read online: https://github.com/ocornut/imgui/tree/master/docs

// CHANGELOG
...
//  2020-09-08: DirectX12: Clarified support for building on 32-bit systems by redefining ImTextureID.

[JackBoosY]

The real problem is that imgui officially stated that imgui should only be used as source files, while imgui is built as a library in vcpkg, which makes it impossible for us to change the value of ImTextureID through this "redefinition" behavior.

If the upstream approve PR ocornut/imgui#1713, this issue can be easily resolved.

cc @ocornut @ras0219-msft

Please note this issue also exists with another variable ImDrawIdx.

[ocornut]

If the upstream approve PR ocornut/imgui#1713, this issue can be easily resolved.

I am not sure I understand how this would solve anything. Build files on the vcpkg repo would be equivalent to build files on imgui repo. It's a matter of whether some compile-time setting can be exposed to the end-user while benefiting from the service of a package manager.

Btw, in the case of SFML-imgui, that particular requirement that it wants unsigned int instead of void* is entirely unnecessary/superfluous and only exist because the maintainer had (at least at the time) an irrational aversion for casting. The unsigned int would perfectly fit in the void* so it is merely syntactic sugar, the trade-off being that to avoid 2-3 casts in their source they required a compile-time change. So if you ask me, there's a simple way to fix the reported issue and it would be to change SFML-imgui to not require this compile-time change and simply do their casts, which would make SFML-imgui compatible with prebuild librairies of dear imgui and thus package managers in general.

(There's still a more general issue allowing to expose any compile-time parameter in a package manager, which I presume isn't easy to solve, but at least this one concrete report can easily be closed).

[ocornut]

Addendum:

Here is the official comments:

Yes and no. That comment you relates to the DX12 backend, because the DX12 backend requires ImTextureID to be 64-bits to compile, which would be lead to the same problem as reported here with the SFML backend. But in the case of the SFML backend there's an obvious fix available.

(Tangential, there was an unconclusive thread about trying to make Dear ImGui default ImTextureID to a 64-bit value: ocornut/imgui#1641)