Linux x86_64 build error - include directories not set correctly in cmake files for dependencies (wxWidgets) #5815
Comments
|
I suppose this is an issue of wxWidgets or of your distro.
ne 17. 1. 2021 v 23:03 odesílatel TheAndr0id <[email protected]>
napsal:
… Version
2.3.0
Operating system type + version
Linux x86_64
Behavior
When building the dependencies for the latest release the following error
occurs when building wxWidgets:
[ 98%] Building CXX object libs/media/CMakeFiles/media.dir/__/__/__/__/src/unix/mediactrl.cpp.o
In file included from /usr/include/gstreamer-1.0/gst/gstbin.h:27,
from /usr/include/gstreamer-1.0/gst/gst.h:35,
from PrusaSlicer-2.3.0/deps/build/dep_wxWidgets-prefix/src/dep_wxWidgets/src/unix/mediactrl.cpp:18:
/usr/include/gstreamer-1.0/gst/gstelement.h:55:10: fatal error: gst/gstconfig.h: No such file or directory
55 | #include <gst/gstconfig.h>
| ^~~~~~~~~~~~~~~~~
compilation terminated.
libs/media/CMakeFiles/media.dir/build.make:110: recipe for target 'libs/media/CMakeFiles/media.dir/__/__/__/__/src/unix/mediactrl.cpp.o' failed
The gstconfig.h file is actually in /usr/lib64/include/gstreamer-1.0/gst.
If it is copied/linked into /usr/include/gstreamer-1.0/gst then the build
completes. The pkg-config file for my install of gstreamer-1.0 includes the
correct include paths. Do the cmake files use this information? For
instance 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
In googling this error, this is a common problem with the gstconfig.h
file. The standard location is for it to be installed is under a 64-bit lib
directory (eg: /usr/lib/x86_64-linux-gnu/gstreamer-1.0/include/gst, or in
my case /usr/lib64/include/gstreamer-1.0/gst)
Many other packages a simple make clean/distclean causes the make process
to re-evaluate the pkg-config paths and cleans up the error in the auto
generated make files.
For now I've created a symlink and that allows the build to continue. I'll
remove the link when 2.3.0 is finished.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#5815>, or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABMPSI5ACYLQ33W64OCTE6LS2NNDHANCNFSM4WGN76QA>
.
|
|
No, this is an issue with your rollout of wxWidgets which the dependencies download from YOUR git server. This isn't static wxWidgets, this is a custom build that your team maintains. I'm guessing this is mainly because the distribution I run (Slackware) does not do 32bit compatibility. It is strictly a x64 system and thus this include file is in a 64bit library location because it has 64bit requirements. There's probably a 32bit version of it as well. You are not passing the correct CFLAGS to your cmake files that your project maintains. This ticket should not have been closed. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Version
2.3.0
Operating system type + version
Linux x86_64
Behavior
When building the dependencies for the latest release the following error occurs when building wxWidgets:
The gstconfig.h file is actually in /usr/lib64/include/gstreamer-1.0/gst. If it is copied/linked into /usr/include/gstreamer-1.0/gst then the build completes. The pkg-config file for my install of gstreamer-1.0 includes the correct include paths. Do the cmake files use this information? For instance on my system:
In googling this error, this is a common problem with the gstconfig.h file. The standard location is for it to be installed is under a 64-bit lib directory (eg: /usr/lib/x86_64-linux-gnu/gstreamer-1.0/include/gst, or in my case /usr/lib64/include/gstreamer-1.0/gst)
Many other packages a simple make clean/distclean causes the make process to re-evaluate the pkg-config paths and cleans up the error in the auto generated make files.
For now I've created a symlink and that allows the build to continue. I'll remove the link when 2.3.0 is finished.
The text was updated successfully, but these errors were encountered: