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

Compile error in Glaxnimate module #915

Open
frdbr opened this issue May 6, 2023 · 10 comments
Open

Compile error in Glaxnimate module #915

frdbr opened this issue May 6, 2023 · 10 comments

Comments

@frdbr
Copy link

frdbr commented May 6, 2023

[ 39%] Building CXX object src/modules/glaxnimate/CMakeFiles/mltglaxnimate.dir/glaxnimate/src/core/io/lottie/cbor_write_json.cpp.o
/home/farid/mlt-git/src/mlt/src/modules/glaxnimate/glaxnimate/src/core/io/lottie/cbor_write_json.cpp:21:6: error: identifier ‘char8_t’ is a keyword in C++20 [-Werror=c++20-compat]
   21 | enum char8_t : uchar {};
      |      ^~~~~~~
cc1plus: all warnings being treated as errors
make[2]: *** [src/modules/glaxnimate/CMakeFiles/mltglaxnimate.dir/build.make:440: src/modules/glaxnimate/CMakeFiles/mltglaxnimate.dir/glaxnimate/src/core/io/lottie/cbor_write_json.cpp.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:1061: src/modules/glaxnimate/CMakeFiles/mltglaxnimate.dir/all] Error 2
make: *** [Makefile:136: all] Error 2
==> ERROR: A failure occurred in build().
    Aborting...
@ddennedy
Copy link
Member

ddennedy commented May 6, 2023

This is still a problem upstream: https://gitlab.com/mattbas/glaxnimate/-/blob/master/src/core/io/lottie/cbor_write_json.cpp#L20

Since we import this as a git submodule based on the latest release, I am going to turn off warnings as errors for anything but Debug builds.

@ddennedy
Copy link
Member

ddennedy commented May 6, 2023

For now you can try building (requires a clean build directory) with CXXFLAGS environment variable containing -Wno-c++20-compat.

ddennedy added a commit that referenced this issue May 6, 2023
Related to #915. I do not want bug reports about compile errors for code
that we have little control over. Now, at least the user can
@frdbr
Copy link
Author

frdbr commented May 6, 2023

Since I'm running from a PKGBUILD arch script I couldn't figure out how to properly add the CXXFLAGS but changing the build type from Debug to Release fixes it.

@frdbr
Copy link
Author

frdbr commented May 6, 2023

If this is a good enough answer I can close it.

@ddennedy
Copy link
Member

ddennedy commented May 6, 2023

I just ran into this too on msys2 (Windows) for Shotcut daily. This happened because Arch and msys2 upgraded gcc from major version 12 to 13. Do not close; I want to track fixing this in a Debug build for a future version of glaxnimate.

@ddennedy
Copy link
Member

ddennedy commented May 6, 2023

Reported upstream: https://gitlab.com/mattbas/glaxnimate/-/issues/603

@bmatherly
Copy link
Member

Dan,
I agree with your approach here. I would like OUR builds to fail on warnings, but 3rd party builds to succeed. Should we update our daily build actions to build for debug? Or I could add another switch that we could enable in our builds.

@ddennedy
Copy link
Member

ddennedy commented May 7, 2023

Depends on what you mean by “OUR.” If you mean local then set the CMAKE_BUILD_TYPE=Debug
If you mean Shotcut daily then no.
If you mean melt on macOS daily and Linux on push, then yeah we can set that up.

@bmatherly
Copy link
Member

I already make my local builds with CMAKE_BUILD_TYPE=Debug. That that does not catch them all for some reason (compiler versions, I suppose).

I was thinking we could enable it for all these builds:
https://github.com/mltframework/mlt/actions

Shotcut? Maybe someday in the future. I dunno.

@ddennedy
Copy link
Member

ddennedy commented May 7, 2023

Ok but not the Docker build. I already have a local change yet to push to update the gitlab pipeline with more recent Fedora and turn on debug. That will catch more. But I don’t think we’ll ever catch them all. The case of Glaxnimate is more difficult as it is a git submodule, and we don’t yet have a way to set a separate build type for that module if that is even possible, which I doubt.

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

3 participants