So when I run:
gcc `pkg-config --cflags --libs gtk+-3.0` -o program-name code.cpp
to compile my program against the gtk3 libraries, I get the following error:
Package 'xfixes' requires 'fixesproto >= 6.0' but version of fixesproto is 5.0
This error only shows up when trying to compile against gtk+3.0, not against
any of the other libraries with compatible .pc files for pkg-config.
I installed gtk+3.0 libraries through synaptic package manager, so I assume
everything needed was installed, so I don't really have any idea what this
error message means, or how to fix it.
Related
I have a C++ application that uses WxWidgets. It compiles perfectly with g++ on my computer.
However I need to run the application on a Raspberry Pi 3. Compiling directly on Raspi takes almost an hour.
So I want to do a cross compilation: compile it on my computer and copy the executable to raspberry.
I tried to follow a tutorial, however the generated file is an "x86-64" file:
http://yasriady.blogspot.com/2015/10/how-to-build-wxwidgets-for-raspberry-pi.html
My computer:
Ubuntu 20.04.2 LTS;
g++ 9.3.0;
wxWidgets v3.1.5.0;
build flags for my computer: CC_FLAGS=-std=c++17 -w -c -rdynamic -W wx-config --cxxflags --libs --gl-libs geos-config --cflags -lgeos -lglut -lGLU -lGL -lm -lGLEW .
Should I re-install wxWidgets for arm? I'm new to cross-compilation
Thank you so much
I already have wxWidgets installed and compiling for x86. Afterwards, I installed wxWidgets for arm-linux following the tutorial.
When I run "make for the examples from the samples folder, the generated file is for x86.
Maybe "make" is compiling using the x86 compiler, not the newly installed arm compiler.
You should be able to cross-compile for RPi without any problems, double check that you've specified the correct --host option and didn't get any errors from configure (if you did, look at config.log to see why).
I'm working on Solaris 11.3 with Sun Studio 12.5. When I attempt to configure with Cmake out-of-tree, Cmake finishes with configuration errors and does not produce the makefiles. In-tree may be broken, too. But our procedures say to build out-of-tree, so that;' what I do.
I have nearly no Cmake experience. Others contributed the the CMake files, and I struggle with tasks related to them. I'm not sure if I am doing something wrong, if our Cmake files are broken, or if Cmake is not well tested under Solaris.
What is going on with CMake, and how do I fix it?
Here are the links to the Cmake files. I can copy/paste them, but it just takes up a bunch of space. The files are hosted on GitHub so they should always be available.
CMakefileList.txt
cryptopp-config.cmake
Here is Solaris' Cmake version, prior to me installing 3.6.2:
$ cmake --version
cmake version 2.8.6
Below is from Solaris Cmake version 2.8.6.
cryptopp-build$ export CXX=/opt/developerstudio12.5/bin/CC
cryptopp-build$ export CXXFLAGS="-DNDEBUG -g2 -O2 -D__SSE2__ -D__SSE3__ -D__SSSE3__ -D__SSE4_1__ -D__SSE4_2__ -D__AES__ -D__PCLMUL__ -D__RDRND__ -D__RDSEED__ -D__AVX__ -D__AVX2__ -D__BMI__ -D__BMI2__ -D__ADX__ -xarch=avx2_i"
cryptopp-build$ cmake ../cryptopp
-- The CXX compiler identification is unknown
-- Check for working CXX compiler: /bin/c++
-- Check for working CXX compiler: /bin/c++ -- broken
CMake Error at /usr/share/cmake-2.8/Modules/CMakeTestCXXCompiler.cmake:45 (MESSAGE):
The C++ compiler "/bin/c++" is not able to compile a simple test program.
It fails with the following output:
Change Dir: /export/home/test/cryptopp-build/CMakeFiles/CMakeTmp
Run Build Command:/bin/gmake "cmTryCompileExec/fast"
/bin/gmake -f CMakeFiles/cmTryCompileExec.dir/build.make
CMakeFiles/cmTryCompileExec.dir/build
gmake[1]: Entering directory
`/export/home/test/cryptopp-build/CMakeFiles/CMakeTmp'
/usr/bin/cmake -E cmake_progress_report
/export/home/test/cryptopp-build/CMakeFiles/CMakeTmp/CMakeFiles 1
Building CXX object CMakeFiles/cmTryCompileExec.dir/testCXXCompiler.cxx.o
/bin/c++ -DNDEBUG -g2 -O2 -D__SSE2__ -D__SSE3__ -D__SSSE3__ -D__SSE4_1__
-D__SSE4_2__ -D__AES__ -D__PCLMUL__ -D__RDRND__ -D__RDSEED__ -D__AVX__
-D__AVX2__ -D__BMI__ -D__BMI2__ -D__ADX__ -xarch=avx2_i -o
CMakeFiles/cmTryCompileExec.dir/testCXXCompiler.cxx.o -c
/export/home/test/cryptopp-build/CMakeFiles/CMakeTmp/testCXXCompiler.cxx
c++: error: language arch=avx2_i not recognized
c++: error: language arch=avx2_i not recognized
gmake[1]: Leaving directory
`/export/home/test/cryptopp-build/CMakeFiles/CMakeTmp'
gmake[1]: *** [CMakeFiles/cmTryCompileExec.dir/testCXXCompiler.cxx.o] Error
1
gmake: *** [cmTryCompileExec/fast] Error 2
CMake will not be able to correctly generate this project.
Call Stack (most recent call first):
CMakeLists.txt:9 (project)
-- Configuring incomplete, errors occurred!
And:
$ /opt/developerstudio12.5/bin/CC -V
CC: Studio 12.5 Sun C++ 5.14 SunOS_i386 2016/05/31
I built Cmake 3.6.2 from sources and installed in /usr/local to attack the CXX compiler identification is unknown issue, but it appears to be having some troubles. As I said earlier, I'm not a Cmake expert (and I'm not sure how one can mess up a make && sudo make install).
cryptopp-build$ cmake ../cryptopp
CMake Error: Could not find CMAKE_ROOT !!!
CMake has most likely not been installed correctly.
Modules directory not found in
/usr/local/bin
CMake Error: Error executing cmake::LoadCache(). Aborting.
Clearing the cache as suggested by #AndrewHenle results in:
# The project GNUmakefile clears all Cmake artifacts because Cmake cannot seem to do it on its own
$ cd cryptopp
$ git status -s
$
$ cd ..
$ rm -rf cryptopp-build
$ mkdir cryptopp-build
$ cd cryptopp-build
# Using 3.6.2 now
$ cmake ../cryptopp
CMake Error: Could not find CMAKE_ROOT !!!
CMake has most likely not been installed correctly.
Modules directory not found in
/usr/local/bin
CMake Error: Error executing cmake::LoadCache(). Aborting.
So there appeared to be two problems. First was the down level Sun supplied Cmake. There's nothing genius about diagnosing it as "too old".
The second issue was more interesting. It appears the CMake Error: Could not find CMAKE_ROOT !!! was cause by sudo make install Once I switched to sudo gmake install the issue went away.
Here are the bug reports on the issue:
Cmake Issue 16302: Cmake fails to identify Sun Studio 12.5 compiler
Cmake Issue 16303: Cmake fails to produce a working installation on Solaris 11.3
I had installed msys2 and mingw-gcc, gtk3 package.
pacman -S mingw-w64-i686-toolchain
pacman -S mingw-w64-i686-gtk3
Then I tried to build a test code.
// main.c
#include <stdio.h>
#include <gtk\gtk.h>
int main()
{
printf("hello, msys2!");
return 0;
}
but this test code wasn't build with error.
main.c:2:21: fatal error: gtk\gtk.h: No such file or directory
I checked gtk.h's location and fixed and rebuilded.
// #include <gtk\gtk.h> -> #include <gtk-3.0\gtk\gtk.h>
C:/msys32/mingw32/include/gtk-3.0/gtk/gtk.h:30:21: fatal error: gdk/gdk.h: No such file or directory
I guess there is my mistake i dont know.
go gtk3 tutorial site.
and read gcc option.
gcc `pkg-config --cflags gtk+-3.0` -o example-0 example-0.c `pkg-config --libs gtk+-3.0`
At the beginning (compiling with MSYS2) I have the same problem and procedure as suggested using the following command (or something like that):
gcc `pkg-config --cflags gtk+-3.0` hello.c -o hello `pkg-config --libs gtk+-3.0`
However the error message remained... So after some internet research I discovery that I have to type (in my case) the following command:
export PKG_CONFIG_PATH=/mingw32/lib/pkgconfig
or
export PKG_CONFIG_PATH=/mingw64/lib/pkgconfig
And them use the compile command previously quoted and then things start to running better and I was able to compile and run my programs.
The sad thing (one of many) is that I have to do this procedure every time I restart the MSYS2. I'm taking suggestions for not have to do it anymore :-)
And the other sad thing is in the fact that after reinstall a new version of MSYS2 (and Codeblocks in my computer) I still able to compile programs, however they are not running due an error with the zlib1.dll.
The message is
"The procedure entry point inflateReset2 could not be located in
the dynamic link library zlib1.dll"
When I compile my program with the command
gcc -o ****** -Xlinker -Bstatic -L/usr/lib -lf2c -lm
an error occurs
usr/bin/ld: cannot find -lgcc_s
Who can tell me the way to solve this error? The version of my system is 32bit Ubuntu 13.04, gcc 4.6. And I had searched the error,somebody said it maybe the error of symlink, but it has the link of /usr/lib/libgcc_s.so to /lib/i386-linux-gnu/libgcc_s.so.1 on my system. I also setted system variable LD_LIBRARY_PATH=/lib/i386-linux-gnu, but it did not work.
It is happening when I add -Bdynamic to the command,gcc compile successfully.The commands of compiling program with archive library and dynamic library are different.Maybe it is the explanation of "cannot find -lgcc_s"
I get the mongo-c-driver from official website, as follows:
$git https://github.com/mongodb/mongo-c-driver.git
$cd mongo-c-driver
$./autogen.sh
$ make
$ sudo make install
Deal.c:2:19: fatal error: mongo.h: No such file or directory
However,when I run my C file named "Deal.c" like this:
gcc -o Deal Deal.c -l /usr/local/include -L /usr/local/lib -lmongoc
Error:#include "mongo.h"
^ compilation terminated.
My system version: is Ubuntu 13.10
It appears that you are missing the path to the headers as well as the locations of the libraries. One option would be to install to the same prefix that your platform uses, such as:
./configure --prefix=/usr --libdir=/usr/lib64
If that is not an option, then you can update your Makefile to include the proper library and include path as such:
gcc Deal.c -L/usr/local/lib -I/usr/local/include/libmongoc-1.0 -I/usr/local/include/libbson-1.0 -lmongoc-1.0 -lbson-1.0
This will typically be done automatically for you by using pkg-config on Unix'like systems as such:
gcc Deal.c $(pkg-config --cflags --libs libmongoc-1.0)
However, if you install into a non-standard path such as /usr/local, then you will need to let pkg-config know where to find the libmongoc-1.0.pc file, such as:
PKG_CONFIG_PATH=/usr/local/lib/pkgconfig gcc Deal.c $(pkg-config --cflags --libs libmongoc-1.0)