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

Linux x86_64 build error (wxWidgets) - GStreamer includes not cmaking correctly #6160

Closed
TheAndr0id opened this issue Mar 2, 2021 · 4 comments
Labels

Comments

@TheAndr0id
Copy link

Version

2.3.0

Operating system type + version

Linux x86_64 (Slackware current)

Behavior

(Please see issue #5815 for extra details - that issue was closed with no resolution or investigation)

After MUCH digging, this is an issue with how GStreamer's includes are found by cmake.

As mentioned above, part of the GStreamer library has include files which are located in a non standard location. In my case they are under /usr/lib64/gstreamer-1.0/include. Other distributions place these header files in different locations. This normally isn't a problem since pkg-config has this information. For example on my system:

> pkg-config --cflags-only-I gstreamer-1.0        
-I/usr/include/gstreamer-1.0 -I/usr/lib64/gstreamer-1.0/include -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include

But... in the included wxWidgets dependency (found here: https://github.com/prusa3d/wxWidgets) the includes are found using the https://github.com/prusa3d/wxWidgets/blob/master/build/cmake/modules/FindGSTREAMER.cmake file. This script creates all of the GSTREAMER_* variables used by the rest of the cmake system. It also uses pkg-config to find the correct includes and libs. This is all good, but...

It creates the following:

GSTREAMER_INCLUDE_DIRS:PATH=/usr/include/gstreamer-1.0
PC_GSTREAMER_INCLUDE_DIRS:INTERNAL=/usr/include/gstreamer-1.0;/usr/lib64/gstreamer-1.0/include;/usr/include/glib-2.0;/usr/lib64/glib-2.0/include

The second is correct and complete. The first will mostly work, but it's not correct and in the case of the new media controls in 2.3.0, it causes the build of wxWidgets to fail because it needs gstconfig.h which isn't in /usr/include/gstreramer-1.0.

So... the long fix (which I don't think is right - I'm not a cmake guy) is to change the call to GSTREAMER_INCLUDE_DIRS in https://github.com/prusa3d/wxWidgets/blob/master/build/cmake/lib/media/CMakeLists.txt to PC_GSTREAMER_INCLUDE_DIRS. (probably the GSTREAMER_LIBRARIES should be changed too)

Now a brute force fix is to add in this include to ALL the builds by adding the following line before the initial dependencies cmake: (not good, but it works)

export CXXFLAGS="$(pkg-config --cflags-only-I gstreamer-1.0)"
@tamasmeszaros tamasmeszaros added the Build Build issues label Mar 9, 2021
tamasmeszaros added a commit that referenced this issue Mar 9, 2021
We don't need it. Building on Linux causes problems with gstreamer.
fixes #5815, #6160
@tamasmeszaros
Copy link
Contributor

tamasmeszaros commented Mar 9, 2021

Hi @TheAndr0id
Please try to build it from the above commit. We don't use wxMediaCtrl anywhere in PrusaSlicer. If it builds, we can merge it into the master branch.

@TheAndr0id
Copy link
Author

Tested and it compiled clean. Thank you!

Removing the support fixes the issue but doesn't address the underlying problem. For PrusaSlicer that works for me, but someone may want to open a ticket with the wxWidgets project as their cmake files have the same issue.

(They don't use GitHub for issue tracking and I'm not interested in creating another account)

@TheAndr0id
Copy link
Author

This fix did not make it into the 2.3.1 release. I'm reopening to ensure this is included in future releases. It is tagged in the master, and the 2.4-alpha, but not the 2.3 tree. Since this causes problems compiling the 2.3.x line, it kind of needs to be included...

@bubnikv
Copy link
Collaborator

gstreamer is not required to compile on PrusaSlicer 2.4.0-alpha.1

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

No branches or pull requests

3 participants