hi guys i try to run Msys2 and GTK in windows 10 i follow this installation
https://www.gtk.org/docs/installations/windows
when i'am arrived at step 5 ,pacman -S mingw-w64-x86_64-toolchain base-devel , i install all packet
i tested installation , but return me:
gcc -o main.c -pthread pkg-config --cflags --libs gtk+-3.0
Package gtk+-3.0 was not found in the pkg-config search path.
Perhaps you should add the directory containing `gtk+-3.0.pc'
to the PKG_CONFIG_PATH environment variable
No package 'gtk+-3.0' found
bash: gcc: command not found
i add in my windows envairoment variable in the system this path
PKG_CONFIG_PATH
C:\msys64\mingw64\lib\pkgconfig
and i insert in all my .bashrc
this code export PKG_CONFIG_PATH=/mingw64/lib/pkgconfig:/mingw64/share/pkgconfig
but nothing return me always the same error
anyone can help me ? or have some suggestions , thanks
The instructions you linked to say to install the mingw-w64-x86_64-gtk3 package. That is a package for the 64-bit MinGW environment provided by MSYS2. Therefore, to use it, you must start MSYS2 by running mingw64.exe from the MSYS2 installation directory, or using the corresopnding shortcut in your start menu. You can type echo $MSYSTEM and if it returns MINGW64 then you are using the right environemnt. You should not need to edit PKG_CONFIG_PATH yourself in your .bashrc.
In case this might help you or somebody else: I've had the same problem happen in a build using MSYS2 - not for GTK3 but for a bunch of different libraries. The PKG_CONFIG_PATH was definitely exported correctly and its path was also correct but pkg-config would stubbornly search in its default search paths instead of the ones provided outside of the MSYS2 install. I tried exporting the variable and setting it through the .bashrc file but that got me nowhere.
I'm not fully sure why it works but, reading through some old company internal docs, I read that installing the dos2unix utility automagically fixed the problem and it did work for me. Install it using pacman -S dos2unix. You might want to update your package list first with pacman -Syu to have up to date packages.
Related
I have installed Qt 5.1.4 but when I 'make install' it shows
Package Qt5Gui was not found in the pkg-config search path.
Perhaps you should add the directory containing `Qt5Gui.pc'
to the PKG_CONFIG_PATH environment variable
No package 'Qt5Gui' found
Package Qt5Widgets was not found in the pkg-config search path.
Perhaps you should add the directory containing `Qt5Widgets.pc'
to the PKG_CONFIG_PATH environment variable
No package 'Qt5Widgets' found
Package Qt5Multimedia was not found in the pkg-config search path.
Perhaps you should add the directory containing `Qt5Multimedia.pc'
to the PKG_CONFIG_PATH environment variable
No package 'Qt5Multimedia' found
But I installed this software qt-opensource-linux-x64-5.14.0.run, after I tried to find them I ran locate Qt5Gui but no Qt5Gui.pc returned,so how can i get Qt5*.pc on my ubuntu 20.04 ?
The installation I started was missing a few more packages
The complete installation should look like this
sudo apt install qtmultimedia5-dev qt5-default -y
The construction of the qt compilation environment requires more than the installation package downloaded from the official website
It worked for me !
Now i can find the Qt5*.pc !
You need to install qtbase5-dev which is part of qt5-default
see: https://packages.ubuntu.com/bionic/amd64/qtbase5-dev/filelist
EDIT: you may also have to install the package qtmultimedia5-dev.
I'm trying to install omnetpp 5.2.1 on windows 10. But getting an error while doing ./configure command related to QT environment. I tried changing the configure.user file in omnetpp package to change the path of QT but still its not working. Here is the error:
configure:error: Qtenv cannot find qmake--maybe it is not in the path
or has some exotic name (tested names were: qmake qmake-qt5 qmake5)-
disabling Qtenv. You can try setting QT_PATH variable in
configure.user to a valid location.
qt5 might not be installed.
sudo apt install qt5-default worked for me while installing on Ubuntu 20.04.
OMNeT++ comes with all dependencies bundled. As long as you have executed the mingwenv.cmd and running from that shell, qmake should be available in the path (in tools/win64/mingw64/bin). Check if qmake.exe is present there. If not, make sure that ZIP file you have downloaded is intact. Standard windows unzip may fail on certain systems...
run ./configure WITH_QTENV = no
ERROR: /home/kenny/Downloads/tensorflow-1.5.0-rc1/tensorflow/contrib/lite/toco/BUILD:326:1: Linking of rule '//tensorflow/contrib/lite/toco:toco' failed (Exit 1)
/usr/bin/ld: warning: libcublas.so.9.1, needed by bazel-out/k8-py3-opt/bin/_solib_local/_U_S_Stensorflow_Scontrib_Slite_Stoco_Ctoco___Utensorflow/libtensorflow_framework.so, not found (try using -rpath or -rpath-link)
Check this issue comment
https://github.com/tensorflow/tensorflow/issues/15656#issuecomment-362104182
The current version of TensorFlow (1.7) does not support CUDA9.1, but you should have several options:
Downgrade to CUDA 9.0
Compile TensorFlow from the source code by your own
Find an existing whl file for you (unofficial release). ex. I fixed the issue by using a whl from https://github.com/mind/wheels
Wait until Tensorflow supports CUDA9.1 :)
Looks like you need to install Cuda 9.1 from Nvidia as a prerequisite to building from source.
I also had similar issue. Probably adding this flag --action_env="LD_LIBRARY_PATH=${LD_LIBRARY_PATH}" in your bazel build command will solve the issue. Make sure you have set the environment variable LD_LIBRARY_PATH as /usr/local/cuda/lib64 or wherever your cuda toolkit installation is present.
EDIT: In case setting up environment variable doesn't work. You can further try by running sudo ldconfig -v|grep 'libcublas.so.9.1'. In my case cuda's version is 9.1 hence I verify for the same. If grep doesn't return the expected library, just try other ways to register your path to ldconfig
It's a weird dynamic link lib error.
Somehow bazel doesn't recognize LD_CONFIG. You'll have to manually update the /etc/ld.so.conf (in my case with Ubuntu 17.1, the config files are in /etc/ld.so.conf.d), and add a line that points to the /usr/local/cuda/lib64 folder.
Then run
sudo ldconfig
to re-build the ld cache. You can verify that the cuda libs are in the search folders by
sudo ldconfig -v | grep cuda
The build should work now.
I've installed CMake 2.8.11.2 package from CMake's website for Mac 64-bit. We recently upgraded a project from Qt 4 to Qt 5 and the CMake upgrade is mandatory for CMake to use Qt 5. However, when I type cmake . I get the following error:
CMake Error: Could not find CMAKE_ROOT !!!
CMake has most likely not been installed correctly.
Modules directory not found in
/Applications/CMake 2.8-11.app/Contents/bin
CMake Error: Error executing cmake::LoadCache(). Aborting.
I can confirm, there is no modules directory in the bin folder. I really don't know how to resolve this error, or how to get the modules needed.
Do hash -r to clear the cache, then do cmake --version.
It should work.
I had the same problem after upgrading on Ubuntu.
Removing cmake and the cmake-data package before performing the update solved it for me.
sudo apt-get remove cmake cmake-data
Now perform the update via
sudo -E add-apt-repository -y ppa:george-edison55/cmake-3.x
sudo -E apt-get update
sudo apt-get install cmake
This worked for me :
cd cmake-3.4.3
./bootstrap --prefix=/usr
make
sudo make install
Additionally, you may encounter the same error when running CMake from Cygwin. This may be caused by a PATH variable listing /bin before /usr/bin: in this case CMake is launched as /bin/cmake instead of /usr/bin/cmake, and trying to load modules from //share/cmake-X.Y.Z (which is a UNC path on Windows) instead of /usr/share/cmake-X.Y.Z.
Explicitly export'ing a correct CMAKE_ROOT isn't helpful, and cmake keeps displaying the same misleading message.
The issue can be solved by setting PATH to /usr/bin:/bin:/everything/else in your .bash_profile.
I was able to fix this error on Linux (for other who may be searching for answer on Linux) while trying to upgrade cmake 2.8.11 to 2.8.12 by exporting the CMAKE_ROOT environment variable like so:
export CMAKE_ROOT=/path_to_install/cmake-2.8.12.2-Linux-i386/share/cmake-2.8
The share directory should be on the same level as your bin directory.
I got the same error message upgrading cmake-3.5.1 to cmake-3.7.1 on Ubuntu 16.04.01 LTS. I just updated the repositories with
sudo apt-get update
Then
cmake --version
brought up the correct and upgraded cmake version and the error messages was gone.
In my opinion/case this is a developer "problem". I suspect this occurs mostly to new developers so I go a bit deeper to put it in the right perspective:
To "not mess with" the original system files used for daily work and separate the new compiled and volatile programs in a separate location it is common to not just change but add/mount a complete folder structure similar to the original OS folder structure in a special "development" location.
So more or less a mirrored folder structure of the original one but connected/linked to the original resources.
There for we need to add an environment variable to our user bash profile where we tell the system: "link our development folders to the following direction/dir."
On Arch Linux this is done in a file in ~/.bashrc - that is linked/forwarded in/by the ~/.bash_profile ("~" stands for /home/your user name/) and MacOS/Unix will be similar.
To do that there are 2 ways:
you can open the .bashrc file and add your environment path to the bottom of it
or
you can use "export" to put the environment variables to the right place in your user bash file.
for kde development e.g. you need to add a path at the end of the ~/.bashrc file like so:
# Adding the kdesrc-build directory to the path
export PATH="$HOME/kde/src/kdesrc-build:$PATH"
what basically tells the system: the development is done in the /home/user name/kde/src folder - there are your files. You can choose where you want to locate your development environment.
If you execute cmake it "thinks" your files are in the original OS folder and the "Could not find CMAKE_ROOT" - message will disappear because it finds all your files since properly linked from your development folder structure to your system folder structure.
So basically to solve the problem you could just execute cmake in the right system folder - it just could mess up your system if the program or make files are not proper done so it is pulled to the home folder development folder structure. And you just have to tell that cmake, so it can find all needed files to compile your stuff, including the CMAKE_ROOT.
Another problem could be that cmake isn't properly installed.
On Arch Linux systems that can be made sure by using the "sudo pacman -Syu cmake" command and it copies the files in the right direction and sets the right user variables to get it executed and reinstall cmake if necessary.
Btw, if you are on other systems like Debian make sure to use a Debian apt repository, it can differ from the Ubuntu repository, especially if you compile for the chosen system.
I tried to write a general "beginners in mind" overview to get em a fundamental picture. Executing cmake in the right folder solved that exact problem for me that was asked for.
(Actual that flags works for the actual cmake version from the official arch repository:
1:
cd /home/ivanovic/kde/src/program_name
than:
2:
cmake -S/home/ivanovic/kde/src/program_name -B/home/ivanovic/kde/build/program_name -DCMAKE_INSTALL_PREFIX=/home/ivanovic/kde/usr -DCMAKE_BUILD_TYPE=Debug
Pay attention that between -S and /home/... is no space, same at -B and /home/...
This worked fine for my kde system software builds.
)
If anyone gets the following error:
Modules directory not found in
/usr/share/cmake-3.20
cmake version 3.20.2
Solution which worked for me:
sudo cp -r /share/cmake-3.20 /usr/share/
The above command copies the cmake-3.20 directory from /share to /usr/share
This also happened to me on a fresh install of Ubuntu 21.04 and was fixed by installing it from "snap":
sudo snap install cmake --classic
(and then making sure that /snap/bin is in $PATH)
tl;dr: check the permission of folder /usr/local/share/cmake-x.xx.
I had a similar problem with the cmake that I build from source code. I compile the code with the following command.
./configure
make
sudo make install
and the binary files were placed into /usr/local/bin as expected. But I will encounter the same problem when executing cmake without sudo privilege. This is because the normal user don't have reading permission with folder /usr/local/share/cmake-3.xx.
The error went away when I give myself the permission to read/execute, with the command.
sudo chmod 755 /usr/local/share/cmake-3.xx
(xx will be the specific version that you installed.)
I downloaded Valgrind 3.7.0 and ran:
./configure
make
make install
However when I run valgrind --version, I get 3.5.0. How is this possible? I am running Mac OS X Lion 10.7. I know I downloaded 3.7.0 because the tar file I downloaded from Valgrind's website name isvalgrind-3.7.0.
What other ways can I check for the version?
By default, valgrind binaries should get installed in /usr/local/bin when you compile from source without providing a --prefix.
(You really just did ./configure && make && make install and had the permissions to install, right?)
See if /usr/local/bin/valgrind exists.
Execute /usr/local/bin/valgrind --version. What is the version?
Execute which valgrind. This should tell you where the valgrind binary is being picked from. Is it the same? My guess is, it is probably not.
Execute echo $PATH to see your path. This gives a : delimited list of directories where bash searches for executables, in the order in which the directories are listed.
My guess is:
There is an existing valgrind installation of the old version, and it shows up in a directory that appears earlier in your $PATH than /usr/local/bin.