remove non-existent function calls#358
Conversation
`ImGui_ImplOpenGL3_DestroyFontsTexture` and `ImGui_ImplOpenGL3_CreateFontsTexture` were removed on 04.06.2025
63394d8 to
f325c67
Compare
|
@nmwsharp This PR fixes compilation/linking errors. Would appreciate your review and merge 😊 |
|
Hi! Thanks for submitting this. Pardon the delay.
Right now this library uses ImGui 1.91.9b, which looks to be before this change. Next time we bump the dependency I will certainly remove those, but I don't think it makes sense to remove them before bumping the dependency.
It took me a minute to understand this. The problem is related to doing the define in CMake, which we currently do, right? Adding the define to the source directly makes sure our functions compile even if the target was defined elsewhere? I think that makes sense to me, thanks for the fix.
Good catch, thanks. |
|
For now I'll remove the ImGUI change so I can merge this PR with the other two. |
This reverts commit 9b4159c.
|
Hmmmm, note the build failures from the CI. I think to use It's been 2 years since I had to think about C++ symbol visibility, so I might be missing something basic here. |
|
Sorry, for the delay on my end too! The problem with STB is indeed present. The fix I proposed here worked for me because I had a binary linking to both polyscope and stb (by including it). Therefore I had some double definition errors. When I removed STB from my dependencies (moved to wuffs), I got the no-definition linker errors. Not sure how to fix this then Since it's been half a year since I opened this PR, I no longer have the context in my head ;( I used CPM package manager and I believe the imgui and glm were downloaded by it and had latest versions. polyscope's cmake has find_package I believe so it picked them up. I personally would encourage to use a package manager but since I am the only one with these issues (and I am using a pm), I guess it's my problem :) The glm fix is harmless and useful though, lets only keep this one. And yes, you understood everything correctly. The define in cmake only happens if glm isn't present on the system. But if it is, then there is no define propagated to it. |
ImGui_ImplOpenGL3_DestroyFontsTextureandImGui_ImplOpenGL3_CreateFontsTexturewere removed on 04.06.2025If glm is already a target then no GLM_ENABLE_EXPERIMENTAL define might be specified for it. A more robust way is to define it explicitly
Lets say we have 3 projects: A, B, C. A depends on B and C, both of which use stbi. If stb implementation is not marked as static then you get multiple definition errors during link time because stb implementation symbols are exposed in a compiled library