[imgui] issue with opengl bindings #14753
Comments
|
Is this a build issue or usage issue? I can build imgui succesfully. |
|
Build Issue. glew symbol is included, when it should not. |
|
See this minimum reproduce. |
|
Confirmed. |
JackBoosY
added
category:port-bug
|
@RT222 Seems most of these binding features are missing export the dependency libraries. Can you confirm this? |
|
I'm sorry about this, but this problem is beyond my comprehension, and I currently lack the time to dig into it. If it helps, I can revert my changes to get back to the old fashioned way of including the sources files manually. |
|
@RT222 Fine, I will handle this. |
|
Same issue here. |
ProblemI have both GLEW and Glad installed by Vcpkg, as I need them both for different projects. Dear ImGui doesn't work for the project with Glad (and it was working fine before). The latter project uses the Glad loader with SDL2 window therefore I used the following command to install Dear ImGui: However, this resulted in linker errors similar to the ones in the OP's post. My application then linked fine but it crashed on Root causeI've found out with Visual Studio debugger that Turns out that ImGui was compiled by Vcpkg with wrong header included in imgui_impl_opengl3.cpp. The question is, why was the GLEW header used instead of Glad header? So it seems that the OpenGL loader is automatically detected by preprocessor based on available header files. Unfortunately, due to the order of WorkaroundI guess uninstalling Glew or using separate Vcpkg installation with only one loader installed would work. However, I find those workarounds too annoying and managed to find another way to fix it. See the following change in Vcpkg: diff --git a/ports/imgui/CMakeLists.txt b/ports/imgui/CMakeLists.txt
index f6f85b29e..4aa77096e 100644
--- a/ports/imgui/CMakeLists.txt
+++ b/ports/imgui/CMakeLists.txt
@@ -81,6 +81,7 @@ endif()
if(IMGUI_BUILD_OPENGL3_GLAD_BINDING)
find_package(glad CONFIG REQUIRED)
target_link_libraries(${PROJECT_NAME} PUBLIC glad::glad)
+ target_compile_definitions(${PROJECT_NAME} PUBLIC IMGUI_IMPL_OPENGL_LOADER_GLAD)
target_sources(${PROJECT_NAME} PRIVATE ${CMAKE_CURRENT_SOURCE_DIR}/backends/imgui_impl_opengl3.cpp)
endif()I hope it helps somebody with a similar issue. Also, please consider adding the compile definitions for all loaders. It will ensure that the correct variant is installed even when there are multiple OpenGL loaders installed already. Another thing to consider is to somehow make it so that multiple ImGui variants can be installed at the same time in one Vcpkg installation but that's another issue. |
|
@MrSimbax According to the code in exmaples/example_glfw_opengl3/main/cpp line 83-99: #if defined(IMGUI_IMPL_OPENGL_LOADER_GL3W)
bool err = gl3wInit() != 0;
#elif defined(IMGUI_IMPL_OPENGL_LOADER_GLEW)
bool err = glewInit() != GLEW_OK;
#elif defined(IMGUI_IMPL_OPENGL_LOADER_GLAD)
bool err = gladLoadGL() == 0;
#elif defined(IMGUI_IMPL_OPENGL_LOADER_GLAD2)
bool err = gladLoadGL(glfwGetProcAddress) == 0; // glad2 recommend using the windowing library loader instead of the (optionally) bundled one.
#elif defined(IMGUI_IMPL_OPENGL_LOADER_GLBINDING2)
bool err = false;
glbinding::Binding::initialize();
#elif defined(IMGUI_IMPL_OPENGL_LOADER_GLBINDING3)
bool err = false;
glbinding::initialize([](const char* name) { return (glbinding::ProcAddress)glfwGetProcAddress(name); });
#else
bool err = false; // If you use IMGUI_IMPL_OPENGL_LOADER_CUSTOM, your loader is likely to requires some form of initialization.
#endifDoes this confirm that these features are in conflict? |
|
@JackBoosY https://github.com/ocornut/imgui/blob/ad5d1a8429ea219d3d34e6a36a48918650402697/backends/imgui_impl_opengl3.h#L68 this would led to the definition of the flags. |
|
@mathisloge Therefore, these definitions should not be added to the compilation options, because they will be automatically defined. |
JackBoosY
added
category:question
|
@JackBoosY the auto detection is just a fallback and might interfere with system includes or eg. if glew is already installed in vcpkg. We should be really explicit here and don't use the auto detection. I think @Dylan-Davies has a point there (#19231 (comment)). Since these preprocessors would be evaluated at vcpkg-build time. |
|
Just as a sidenode: if there is a loader defined beforehand, the auto detection would be disabled. |
|
@mathisloge Make sence, but we should wait for the upstream reply first. |
|
anyone pinged upstream? 😄 |
|
@dg0yt what do you think about since you are the contributor. |
@JackBoosY Contributor of what? |
Sorry for ping the wrong guy. |
|
cc @ocornut, the imgui owner. |
|
Hello, I posted an answer at ocornut/imgui#4390 |
JackBoosY
added
category:port-bug
|
@JackBoosY so with the answer ocornut gave: |
|
@mathisloge Will fix later. |
|
@mathisloge Yes, I will fix this in the nearly feature. |
|
We decided to bite the bullet and we are working toward embedding our own minimalist OpenGL loader into the backend, in order to put in end to that endless amount of confusion/misery caused by the OpenGL loaders. We already have a version working and we'll either aim to use it in 1.84 or right after 1.84 is released. TL;DR; ihmo don't put effort into solving this on your end. |
|
The dear imgui opengl backend now embeds its own loader, simplifying a lot the trouble people had and hte packaging problem for vcpkg. See ocornut/imgui#4445 |
JackBoosY
added
the
depends:upstream-changes
|
Close this PR until upstream fixes this. |
Is your feature request related to a problem? Please describe.
vcpkg install imgui[opengl3-glbinding-binding,glfw-binding]:x64-windowswill build with glew.resulting
Proposed solution
So lets make the problem clear first. For opengl there are two types of helper library commonly used.
In this case, imgui[opengl3-glbinding-binding,glfw-binding] is actually built as imgui[opengl3-glew-binding,glfw-binding], resulting glew symbols in the
imguid.libfile.This should be fix.
Describe alternatives you've considered
Even the above issue is fixed, there will be potential problem:
since there will be no way to let one installation of vcpkg to supply polymorphic
imgui.lib, this problem will never be solved if vcpkg building bindings into library code.The only solution I can come up with is copying bindings
imgui_impl_*.cppfiles into imgui'sincludefolder. Let the use doand let the user compile this source and link the obj file to its executable.
The text was updated successfully, but these errors were encountered: