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.

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

undefined symbol: flextGLInit #616

Closed
bansan85 opened this issue Apr 24, 2023 · 4 comments
Closed

undefined symbol: flextGLInit #616

bansan85 opened this issue Apr 24, 2023 · 4 comments

Comments

@bansan85
Copy link
Contributor

I'm trying to use Magnum v2020.06 with GL support for Android.

I checked by reading code in master branch, I still see this problem. I can't build with master because of API break.

flextGLInit look to be defined in MagnumExternal/OpenGL/GLES3 (because I use GLES3)

After reading MagnumExternal/OpenGL/GLES3/CMakeLists.txt, MagnumOpenGL_SRCS is set to flextGL.cpp.

In flextGL.cpp, there is no definition of flextGLInit.

So, in Magnum\Platform\GLContext.h, the following is failing because flextGLInit is defined only for CORRADE_TARGET_EMSCRIPTEN or CORRADE_TARGET_WINDOWS AND MAGNUM_TARGET_DESKTOP_GLES :

            #ifndef CORRADE_TARGET_EMSCRIPTEN
            GL::Context{NoCreate, args, argc, argv, flextGLInit} {}
            #else
            GL::Context{NoCreate, args, argc, argv, nullptr} {}

Do you think there is something wrong ? Where is flextGLInit defined ?

Thanks for your help.

@bansan85
Copy link
Contributor Author

Sorry, I missed to add Magnum::EglContext in CMake.

@mosra
Copy link
Owner

mosra commented Apr 26, 2023

Yes, that was it :)

I can't build with master because of API break.

Can you elaborate? To build with master you need the master branch of Corrade and other Magnum repositories as well. 2020.06 is rather old, but until I manage to tag a new release I'm trying to preserve API compatibility as much as possible, so code from back then should mostly still compile on current master.

@bansan85
Copy link
Contributor Author

After a small look, there is lots of error messages that I could easily fixed. One big error is a forward declaration change in my code.

Finally, I just have the following error:

Utility::Resource rs
rs.get("filename.vert")

Output:

  XXX.cpp:23:19: warning: 'get' is deprecated: use getString() instead [-Wdeprecated-declarations]
    vs.addSource(rs.get("RayCast.vert"));
                    ^
  ZZZ/include\Corrade/Utility/Resource.h:383:9: note: 'get' has been explicitly marked deprecated here
          CORRADE_DEPRECATED("use getString() instead") std::string get(const std::string& filename) const;
          ^
  ZZZ/include\Corrade/Utility/Macros.h:84:50: note: expanded from macro 'CORRADE_DEPRECATED'
  #define CORRADE_DEPRECATED(message) __attribute((deprecated(message)))
                                                   ^
  XXX.cpp:23:19: error: implicit instantiation of undefined template 'std::__ndk1::basic_string<char, std::__ndk1::char_traits<char>, std::__ndk1::allocator<char> >'
    vs.addSource(rs.get("RayCast.vert"));
                    ^
  YYY/Android/Sdk/ndk/21.4.7075529/toolchains/llvm/prebuilt/windows-x86_64/sysroot/usr/include/c++/v1\iosfwd:209:32: note: template is declared here
      class _LIBCPP_TEMPLATE_VIS basic_string;
                                 ^

So, get is now deprecated but I have error: implicit instantiation of undefined template. I added #include <string> to fix it. So, finally, I didn't had too much work to compile with Corrade/Magnum master (but for now, I will still use 2020.06 because it works well and I don't have time to check an update for this library). It's a lot of error messages for few fix to apply.

But it looks like in Corrade/Utility/Resources.h, the following lines doesn't work well.

#ifdef CORRADE_BUILD_DEPRECATED
/* Most APIs took a std::string before, provide implicit conversions */
#include "Corrade/Containers/StringStl.h"
#endif

@mosra
Copy link
Owner

mosra commented Apr 27, 2023

Yes, StringStl.h adds just a forward declaration of std::string where possible. You'll come across a few more such cases, and fixing the errors should mostly be about adding some #include. Which you can do even when compiling against 2020.06, to "future-proof", let's say.

As the point of that deprecation was to get rid of a relatively heavy <string> header in favor of something lightweight, adding it back there for backwards compatibility would basically undo the optimization. So I had to pick a tradeoff :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants