I'm checking with installed protobuf lib version on my system and I'm surprised with, following /usr/bin/protoc --version return V2.4.1 and following protoc --version return V3.0.0.
Why this is so, am I missing any user account related installation concept.
It looks like you have two versions of protocol buffers installed.
If you write $ which protoc you will see where the protoc environment variable points to. Probably /usr/local/bin/protoc
You can change that to /usr/bin/protoc, but how depends on how it is set initially and what system you are on. Google or this article will help you with that.
Related
I wanted to test out Pocketsphinx in Node.JS. It says I need to install Swig version 3.0.7 or above.
I think I installed all the other dependencies correctly. I can even type Swig commands in the Terminal now, but I keep getting this error whenever I run npm install pocketsphinx:
CMake Error at /usr/local/Cellar/cmake/3.6.3/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:148 (message):
Could NOT find SWIG (missing: SWIG_DIR) (Required is at least version
"3.0.7")
Call Stack (most recent call first):
/usr/local/Cellar/cmake/3.6.3/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:388 (_FPHSA_FAILURE_MESSAGE)
/usr/local/Cellar/cmake/3.6.3/share/cmake/Modules/FindSWIG.cmake:75 (FIND_PACKAGE_HANDLE_STANDARD_ARGS)
CMakeLists.txt:4 (find_package)
I tried brew install swig, npm install swig, and npm install -g swig. I tried going to the swig download page and following the installation instructions, but nothing I seem to do stops the error from happening. I'm trying this on a Macbook by the way.
I really have no clue what I'm doing here. I just wanted to test out Pocketsphinx and now I've installed Swig in 4 different places, and CMake can't seem to recognise any of them.
Any help would be wonderful!
Came here looking for the Windows-based error. I found a solution that seems to work for me, so decided to post it here.
Create two environment variables in the "System Variables" section: SWIG_DIR and SWIG_EXECUTABLE. These must point to /path/to/the/swig/dir/ and /path/to/the/swig/dir/swig.exe respectively.
After this, add one more entry to the PATH variable: /path/to/the/swig/dir. Test this out by typing swig in the command prompt. It should display a message must specify an input file. Use -help for available options.
Restart the computer to apply all environment variable changes. find_package(SWIG required) should work correctly now.
Check the source code for the FindSwig.cmake.
Unfortunately, if a find script does not work as expected and you do not see right away why that is the case, you usually have to dig into its source. In your case, it looks like CMake was able to find and run the SWIG executable, but then failed to obtain the swig directory.
Try manually running swig -swiglib and check that the printed directory indeed contains a swig.swg file. Also, be sure that the swig executable found by CMake is actually the correct one (you can verify this by inspecting the value of SWIG_EXECUTABLE in either the cmake-gui, the ccmake curses interface, or in the CMakeCache.txt file directly).
Note that CMake will not update the executable path once it has been found! So if you make changes to your system that influence the executable location, you will have to clear the cache (eg. by deleting the CMakeCache.txt) and re-run CMake for the changes to take effect.
I tried to work it out for myself. The problem was when I typed npm install swig.
I forgot to set up this version of Swig, and the compiler was using it.
I typed sudo npm uninstall swig and it worked perfectly. I feel very stupid!
I am trying to install pysam.
After excecuting:
python path/to/pysam-master/setup.py build
This error is produced:
unable to execute 'x86_64-conda_cos6-linux-gnu-gcc': No such file or directory
error: command 'x86_64-conda_cos6-linux-gnu-gcc' failed with exit status 1
There are similar threads, but they all seem to address the problem assumig administriator rights, which I do not have. Is there a way around to install the needed files?
DISCLAIMER: This question derived from a previous post of mine.
manually installing pysam error: "ImportError: No module named version"
But since it might require a different approach, I made it a question of its own.
You can also receive the same error while installing some R packages if R was installed using conda (as I had).
Then just install the package by executing: conda install gxx_linux-64 to have that command available.
Source:
https://github.com/RcppCore/Rcpp/issues/770#issuecomment-346716808
It looks like Anaconda had a new release (4.3.27) that sets the C compiler path to a non-existing executable (quite an embarrassing bug; I'm sure they'll fix it soon). I had a similar issue with pip installing using the latest Miniconda, which I fixed by using the 4.3.21 version and ensuring I was not doing something like conda update conda.
See https://repo.continuum.io/miniconda/ which has release dates and versions.
It should now be safe to update conda. This is fixed in the following python packages for linux-64:
python-3.6.2-h0b30769_14.tar.bz2
python-2.7.14-h931c8b0_15.tar.bz2
python-2.7.13-hac47a24_15.tar.bz2
python-3.5.4-hc053d89_14.tar.bz2
The issue was as Jon Riehl described - we (Anaconda, formerly Continuum) build all of our packages with a new GCC package that we created using crosstool-ng. This package does not have gcc, it has a prefixed gcc - the missing command you're seeing, x86_64-conda_cos6-linux-gnu-gcc. This gets baked into python, and any extension built with that python goes looking for that compiler. We have fixed the issue using the _PYTHON_SYSCONFIGDATA_NAME variable that was added to python 3.6. We have backported that to python 2.7 and 3.5. You'll now only ever see python using default compilers (gcc), and you must set the _PYTHON_SYSCONFIGDATA_NAME to the appropriate filename to have the new compilers used. Setting this variable is something that we'll put into the activate scripts for the compiler package, so you'll never need to worry about it. It may take us a day or two to get new compiler packages out, though, so post issues on the conda-build issue tracker if you'd like to use the new compilers and need help getting started.
Relevant code changes are at:
py27: https://github.com/anacondarecipes/python-feedstock/tree/master-2.7.14
py35: https://github.com/anacondarecipes/python-feedstock/tree/master-3.5
py36: https://github.com/anacondarecipes/python-feedstock
The solution that worked for me was to use the conda to install the r packages:
conda install -c r r-tidyverse
or r-gggplot2, r-readr
Also ensure that the installation is not failing because of admin privileges.
It will save you a great deal of pain
After upgrading Golang to 1.19.1, I started to get:
# runtime/cgo
cgo: C compiler "x86_64-conda-linux-gnu-cc" not found: exec: "x86_64-conda-linux-gnu-cc": executable file not found in $PATH
Installing gcc_linux-64 from the same channel, has resolved it:
conda install -c anaconda gcc_linux-64
Somewhere in your $PATH (e.g., ~/bin), do
ln -sf $(which gcc) x86_64-conda_cos6-linux-gnu-gcc
Don't put this in a system directory or conda's bin directory, and remember to remove the link when the problem is resolved upstream. gcc --version should be version 6.
EDIT: I understand the sentiment in the comments against manipulating system paths, but maybe we can use a little critical thinking for the actual case in hand before reciting doctrine. What actually have we done with the command above? Nothing more than putting an executable (symlink) called x86_64-conda_cos6-linux-gnu-gcc in one's personal ~/bin directory.
If putting something in one's personal ~/bin directory broke future conda (after it fixes the C compiler path to point to gcc it embeds), then that would be a bug with conda. Would the existence of this verbosely named compiler mess with anything else? Unlikely either. Even if something did pick it up, it's just your system gcc after all...
I have Python3 installed via brew install python3. However, cmake cannot find PythonLibs 3. Here's the header of my CMakeLists.txt.
cmake_minimum_required(VERSION 3.0)
find_package(PythonLibs 3 REQUIRED)
When I ran cmake, I got this error message
Could NOT find PythonLibs: Found unsuitable version "2.7.6", but required is at least "3" (found /usr/lib/libpython2.7.dylib)
Not sure what I did wrong.
In my experience, this happened because I was using an older version of cmake (2.8 instead of 3+) that didn't know about Python 3.4 (it gave up after 3.3.)
The solution was to go into the CMakeLists.txt file and add an "additional versions" directive ABOVE the find_package:
set(Python_ADDITIONAL_VERSIONS 3.4)
find_package(PythonLibs 3 REQUIRED)
You could probably also fix it by upgrading your version of cmake. But the above worked for me with cmake 2.8
Because you are using CMake >= 3.0, you can you find_package(Python COMPONENTS Interpreter Development) see: https://cmake.org/cmake/help/v3.12/module/FindPython.html
That would for instance give you for:
find_package(Python COMPONENTS Interpreter Development)
message("Python_FOUND:${Python_FOUND}")
message("Python_VERSION:${Python_VERSION}")
message("Python_Development_FOUND:${Python_Development_FOUND}")
message("Python_LIBRARIES:${Python_LIBRARIES}")
Results:
Python_FOUND:TRUE
Python_VERSION:3.8.0
Python_Development_FOUND:TRUE
Python_LIBRARIES:/usr/lib/x86_64-linux-gnu/libpython3.8.so
Another reason for this is that CMake can't ever find Python 3 when it is installed from brew on OSX. It looks like the CMake devs know that FindPythonLibs sucks and have a ticket to revamp it but it doesn't look like it will happen any time soon.
I believe the Python interpreter itself knows where its libraries and headers are so I think the best thing to do would be to run it to find out. To get the path to the Python interpreter I would force the user to specify it manually. One of the big issues with Python is that lots of software includes its own copy so you'll end up with 5 copies of it on your system. The chance of picking up the wrong one is just too high. Get the user to specify the correct one.
I installed the luarocks package on Linux Mint, and afterwards installed a couple of rocks such as sudo luarocks install telescope, but when running a script via lua script.lua, require cannot find the module.
Meta: Doing this Q&A style, because while questions that answer this exist, none seem to be generically titled or easily findable, and I hope that I can help someone with this.
In this specific case, the problem was simply that on my distribution, the default Lua version installed was at the time of writing this 5.2, whereas the LuaRocks package was built for 5.1, meaning that Lua 5.2 could not find the rocks due to using different paths for modules.
The solution to the problem was downloading the LuaRocks source code from its github repository, and compiling it for 5.2
./configure --lua-version=5.2
make build
sudo make install
To make sure I can also install packages for LuaJIT, which as of the moment uses 5.1 libs, I have also executed the above lines with lua-version=5.1 beforehand (if I executed them after, the default luarocks command would point at the 5.1 build.
To build LuaRocks, you need liblua5.2-dev and/or liblua5.1-dev
The solution for me is this.
I try
eval "$(luarocks path)"
and it works.
Hope it works for others.
I'm trying to configure the latest version of monodevelop but I'm stuck. I have the latest version of libvala and versions before that. Could someone please explain this to me.
checking for LIBVALA... no
configure: error: Package requirements (libvala-0.12 >= 0.12) were not met:
No package 'libvala-0.12' found
Consider adjusting the PKG_CONFIG_PATH environment variable if you
installed software in a non-standard prefix.
Alternatively, you may set the environment variables LIBVALA_CFLAGS
and LIBVALA_LIBS to avoid the need to call pkg-config.
See the pkg-config man page for more details.
How can I set LIBVALA_LIB? Is LIBVALA a env variable? In the configure.in for the Valabindings it looks like this:
PKG_CHECK_MODULES(LIBVALA, libvala-0.12 >= $LIBVALA_REQUIRED_VERSION)
AC_SUBST(LIBVALA_LIBS)
What is that? How can I solve this?
Under /usr/lib/pkgconfig I have Libvala-0.12.pc if that can help. And if I run dpkg -i libvala-0.12-0 I get that it's installed and works fine.
Do you have libvala-0.12-dev installed? What version of Ubuntu do you have?
The version of libvala required is >= libvala-0.12-dev. Both 0.14 and 0.16 packages are available for Debian Wheezy:
libvala-0.14-dev
libvala-0.16-dev
After installing the package you wish, edit: /extras/Valabinding/configure.in. There is one instance of libvala-0.12. Replace it with the version you want to use (e.g. libvala-0.14).
After making this change, ./configure worked fine.