Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Commenting out viewer.launch() causes linker errors with imgui/glad (no imgui/glad functions called) #33

Open
olkido opened this issue Oct 19, 2021 · 11 comments
Open

Commenting out viewer.launch() causes linker errors with imgui/glad (no imgui/glad functions called) #33

olkido opened this issue Oct 19, 2021 · 11 comments

Comments

@olkido
Copy link

olkido commented Oct 19, 2021

I tried to build a libigil-based project by extending this example. The first thing I tried to do is add an imgui window pane/ menu. I noticed that simply adding the relevant includes and declaring a menu causes the project to not build unless there is an "active" call to viewer.launch() present in the main.cpp code. If the viewer is not launched (for example by commenting the viewer.launch() line out or adding a return() before it -- see the attached main.cpp), I get linker errors due to (it seems) glad.c not having been included among the source files.
I found this very odd (why would simply commenting out viewer.launch() cause linker errors without any functions from imgui/glad being called) so I thought I would share. Is this a known phenomenon?
I am using Xcode 13 (example project built via cmake 3.20.1) . Attaching pictures of my main.cpp and the build log.
Screenshot 2021-10-19 at 17 49 13
Screenshot 2021-10-19 at 17 51 33
@danielepanozzo
Copy link
Contributor

I remember something similar happening to me on xcode a few years ago. Could you try the same setup but asking cmake to create a standard makefile instead of generating an xcode project and check if you still get the error?

@jdumas
Copy link
Collaborator

jdumas commented Oct 19, 2021

Just making sure, but did you add the CMake target igl::opengl_glfw_imgui to the target_link_libraries() command?

@olkido
Copy link
Author

olkido commented Oct 19, 2021

I remember something similar happening to me on xcode a few years ago. Could you try the same setup but asking cmake to create a standard makefile instead of generating an xcode project and check if you still get the error?

Yea without xcode it works. Could it be some xcode (buggy) 'trick' to reduce compilation time (by selectively ignoring files depending on code) ?

Just making sure, but did you add the CMake target igl::opengl_glfw_imgui to the target_link_libraries() command?

I did. If I make sure that viewer.launch() is “active” in the code, Xcode compiles it fine:)

[It's really not a big issue in practise (why would anyone include/declare imgui stuff without running a call to viewer.launch() .... ). We did run across it though while trying to debug something else entirely so I just thought I'd put it out there in case someone else also has this issue. ]

@jdumas
Copy link
Collaborator

jdumas commented Oct 19, 2021

Is this happening when LIBIGL_USE_STATIC_LIBRARY is ON, or OFF? Agree it is a strange issue...

@olkido
Copy link
Author

olkido commented Oct 19, 2021 via email

@danielepanozzo
Copy link
Contributor

I can reproduce it on my machine, I have no idea of where this is coming from. I think @olkido is right, it is probably some further optimization that xcode is doing when compiling the project.

I suggest to close this issue, I don't think it is worth investigating further as it is anyhow a case that will not happen in plausible use cases.

@olkido
Copy link
Author

olkido commented Oct 20, 2021 via email

@avaxman
Copy link

avaxman commented Jan 8, 2022

I literally had the same problem now and this solved it (I looked through the issues first before solving). But srsly wtf.

@jdumas
Copy link
Collaborator

jdumas commented Jan 8, 2022

This was bothering me so I investigated the issue a bit more. Just to recap:

  • This only happens when libigl is compiled in header-only mode.
  • This only happens with the Xcode generator on macOS (using the Makefile generator on macOS will work).

The root of the issue turned out to be uninitialized symbols in glad.c. When commenting out viewer.launch(), the call to gladLoadGLLoader will not be compiled. But this function is responsible for initializing symbols such as glad_glActiveTexture (see here).

Now why is this a problem for Xcode and not Makefile generators? Well, libtool has the following linking option:

-c    Include common symbols as definitions with respect to the table of contents.  This is seldom the intended behav-
      ior  for linking from a library, as it forces the linking of a library member just because it uses an uninitial-
      ized global that is undefined at that point in the linking.  This option is included only because this  was  the
      original behavior of ranlib.  This option is not the default.

(See this Stack Overflow thread for a related discussion)

What happened is that Xcode linked libglad.a without this option, while the Makefile project linked libglad.a with the -c option enabled. If the option is not provided, and gladLoadGLLoader() is not called, symbols such as glad_glActiveTexture will be stripped from libglad.a, leading to undefined references in the final binary.

Finally, the reason this is only an issue when you link against igl::opengl_glfw_imgui, is that this project will be compiling some files that call glad's OpenGL symbols (in the file imgui_impl_opengl3.cpp).

The discrepancy between the Xcode project and the Makefile is either a CMake bug, or a Xcode idiosyncrasy. But in any case there is probably nothing to fix. Either compile libigl statically, or call viewer.launch() in another unused function in your project as a workaround.

@avaxman
Copy link

avaxman commented Jan 8, 2022 via email

@jdumas
Copy link
Collaborator

jdumas commented Jan 8, 2022 •
edited
Loading

Well a simple fix would be to stop pretending the Viewer can be compiled as a header-only library... but I guess we can also add an entry in the FAQ. EDIT: Done.

@jdumas jdumas mentioned this issue Mar 13, 2022
Closed
@alecjacobson alecjacobson mentioned this issue Mar 24, 2022
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Disable glad on apple libigl/libigl
4 participants
@jdumas @danielepanozzo @olkido @avaxman