I'm trying to install the Caffe library but I have a compilation problem due to a wrong protobuf version installed in my system.
In file included from .build_release/src/caffe/proto/caffe.pb.cc:5:0:
.build_release/src/caffe/proto/caffe.pb.h:17:2: error: #error This file was generated by an older version of protoc which is
#error This file was generated by an older version of protoc which is
^
.build_release/src/caffe/proto/caffe.pb.h:18:2: error: #error incompatible with your Protocol Buffer headers. Please
#error incompatible with your Protocol Buffer headers. Please
^
.build_release/src/caffe/proto/caffe.pb.h:19:2: error: #error regenerate this file with a newer version of protoc.
#error regenerate this file with a newer version of protoc.
I followed many of the proposed approaches in the forum and I think that the most similar problem was discussed in this post.
In the caffe.pb.h the control is:
#if 3002000 < GOOGLE_PROTOBUF_MIN_PROTOC_VERSION
#error This file was generated by an older version of protoc which is
#error incompatible with your Protocol Buffer headers. Please
#error regenerate this file with a newer version of protoc.
#endif
However in my system header (/usr/include/google/protobuf/stubs/common.h):
The current version, represented as a single integer to make comparison
easier: major * 10^6 + minor * 10^3 + micro
define GOOGLE_PROTOBUF_VERSION 2005000
From the terminal the command protoc --version returns libprotoc 3.2.0.
So I've installed the 3.2 version but the system headers are not updated.
One user in the previous post commented 'I figured out a way by specifying the protobuf I want first in the PATH variable, without having to remove the other version of protobuf (other things depended on that old version).'
Can someone explain me step by step how can I follow this?
Alternatively can I update the system headers? There are many elements that are connected to the libprotoc so I would like to avoid to damage them.
Thanks
I solved this on my computer and maybe it can help you. My environment is Ubuntu16.04, and I installed Anaconda(for python2.7) before I install Caffe. It happens that I used conda to install libprotobuf-dev, and this leads to conflict with the caffe's 'sudo apt-get install libprotobuf-dev' command, for 'apt-get' and conda installed different on my computer which can be find by 'locate protobuf', so I remove the Anaconda's version of libprotobuf, and no problem happens again.
conda uninstall libprotobuf
conda uninstall protobuf
When you install tensorflow before install Caffe, this problem will also happen, because of the libprotobuf conflict.
Related
I'm having trouble installing the "car" package after upgrading R to 3.6.2 (from 3.4) on Ubuntu 16.04 due to (at least one) dependency (nloptr) that cannot be installed either. It seems to be a problem of the C++ compiler (it is using some deprecated "config" settings, however I'm lost trying to fix this).
I called the following command in R (from the terminal):
install.packages("nloptr")
Error Information:
Installing package into ‘/home/heike/R/x86_64-pc-linux-gnu-library/3.6’
(as ‘lib’ is unspecified)
--- Please select a CRAN mirror for use in this session ---
trying URL 'https://ftp.fau.de/cran/src/contrib/nloptr_1.2.1.tar.gz'
Content type 'application/x-gzip' length 2448313 bytes (2.3 MB)
==================================================
downloaded 2.3 MB
* installing source package ‘nloptr’ ...
** package ‘nloptr’ successfully unpacked and MD5 sums checked
** using staged installation
'config' variable 'CPP' is deprecated
'config' variable 'CXXCPP' is deprecated
checking whether the C++ compiler works... no
configure: error: in /tmp/RtmpPLaJFA/R.INSTALL5e5ed06eeac/nloptr': configure: error: C++ compiler cannot create executables See config.log' for more details
ERROR: configuration failed for package ‘nloptr’
Steps taken so far
changed CRAN mirror and source.list entry
uninstalled and reinstalled R 3.6.2 (also on different machine), same issue remained
System Information
OS Version: Ubuntu 16.04 (x86_64-pc-linux-gnu (64-bit))
R Version: 3.6.2 (2019-12-12)
We have done a lot of work to make nloptr installation better. In essence, you have several choices:
if the system version of the nlopt library is present, use it -- that is the easiest so try installing it via sudo apt-get install libnlopt-dev and then reinstall
if it is not found, then a download of the source and build happens, and this seems to fail on your almost four year old Ubuntu system as it is hard to support all flavours --- but this works swimmingly on newer ones (I run Ubuntu too, but currently 19.10)
there are binaries for you as, see the Ubuntu packages page -- however these may not match your current R version which is mismatches to your distro R version
dependening on where you got R from (did you install a .deb?) you could use the Michael Rutter PPAs to get a current r-cran-nloptr
All this can also be discussed in detail on the r-sig-debian list for R on Debian and Ubuntu.
Edit: In response to the comment below:
To see what package apt knows about, do apt-cache policy r-cran-nloptr. Per the link I gave above we know Ubuntu has a r-cran-nloptr for your (very old) Xenial installation. However it will clash with the very new and current R you have running. Such as the costs of mixing and matching.
To access the Rutter PPAs and its over four thousand current binaries see the fourth paragraph at the top of the Ubuntu at CRAN README
Edit 2: I may have been too pessimistic. The Rutter PPA for the current R binaries has trusty, xenial and bionic. See https://launchpad.net/~marutter/+archive/ubuntu/c2d4u3.5
I'm trying to update GCC on a particular linux machine I have, to a version for which there is no package available.
I run the configure script and it complains about the version of GMP:
# ../gcc/configure
checking build system type... i686-pc-linux-gnu
[snip]
checking for the correct version of gmp.h... no
configure: error: Building GCC requires GMP 4.2+, MPFR 2.4.0+ and MPC 0.8.0+.
Try the --with-gmp, --with-mpfr and/or --with-mpc options to specify
their locations. Source code for these libraries can be found at
their respective hosting sites as well as at
ftp://gcc.gnu.org/pub/gcc/infrastructure/. See also
http://gcc.gnu.org/install/prerequisites.html for additional info. If
you obtained GMP, MPFR and/or MPC from a vendor distribution package,
make sure that you have installed both the libraries and the header
files. They may be located in separate packages.
However, when I check gmp.h it shows:
/* Major version number is the value of __GNU_MP__ too, above and in mp.h. */
#define __GNU_MP_VERSION 4
#define __GNU_MP_VERSION_MINOR 2
#define __GNU_MP_VERSION_PATCHLEVEL 1
and RPM reports the following:
# rpm -q --qf "%{VERSION}\n" gmp
4.2.1
# rpm -q --qf "%{VERSION}\n" gmp-devel
4.2.1
so both library and headers seem to be of a correct version to me (confusingly, the numbering of the .so file for libgmp seems to have exactly nothing to do with the version number... that is showing as
libgmp.so -> libgmp.so.3.4.1
Does anyone know why this might be failing? Those are the only two gmp packages installed on this machine and they are in standard /usr/include and /usr/lib locations, so they should be on the search path already.
Please read Installing GCC:
The difficult way, which is not recommended, is to download the sources for GMP, MPFR and MPC, then configure and install each of them in non-standard locations, then configure GCC with --with-gmp=/some/silly/path/gmp --with-mpfr=/some/silly/path/mpfr --with-mpc=/some/silly/path/mpc, then be forced to set LD_LIBRARY_PATH=/some/silly/path/gmp:/some/silly/path/mpfr:/some/silly/path/mpc/lib in your environment forever. This is silly and causes major problems for anyone who doesn't understand how dynamic linkers find libraries at runtime. Do not do this. If building GCC fails when using any of the --with-gmp or --with-mpfr or --with-mpc options then you probably shouldn't be using them.
Just run ./contrib/download_prerequisites and save yourself a lot of time and pain.
Turns out that "Building GCC requires GMP 4.2+" is insufficiently detailed. Digging into configure, it's actually checking:
#if GCC_GMP_VERSION < GCC_GMP_VERSION_NUM(4,2,3)
choke me
#endif
i.e. GMP 4.2 .3 or greater, so my 4.2.1 wasn't cutting it.
I've previously installed caffe and Fast-RCNN, so I should have all the required libraries and dependencies.
I need to install it again for another repository(https://github.com/ronghanghu/natural-language-object-retrieval) that uses Caffe.
When I run
make all
it gives me the following error:
CXX .build_release/src/caffe/proto/caffe.pb.cc
In file included from .build_release/src/caffe/proto/caffe.pb.cc:5:0:
.build_release/src/caffe/proto/caffe.pb.h:12:2: error: #error This file was generated by a newer version of protoc which is
#error This file was generated by a newer version of protoc which is
^
.build_release/src/caffe/proto/caffe.pb.h:13:2: error: #error incompatible with your Protocol Buffer headers. Please update
#error incompatible with your Protocol Buffer headers. Please update
^
.build_release/src/caffe/proto/caffe.pb.h:14:2: error: #error your headers.
#error your headers.
^
In file included from .build_release/src/caffe/proto/caffe.pb.cc:5:0:
.build_release/src/caffe/proto/caffe.pb.h:26:55: fatal error: google/protobuf/generated_enum_reflection.h: No such file or directory
#include <google/protobuf/generated_enum_reflection.h>
compilation terminated.
make: *** [.build_release/src/caffe/proto/caffe.pb.o] Error 1
I thought maybe protobuf has been updated, and tried
protoc --version
which returns
libprotoc 2.5.0
It seems like newer version of protobuf has been released (2.6 or up).
So my question would be:
1) Is there a simple way to update it?
2) If I do update it, will it affect caffe and fast-rcnn that I previously installed, which depends on the older version of protobuf?
I suspect your problem is that you have multiple versions of protobuf in your include path. It may be picking up the headers from the older version instead of the latest. I can confirm that latest caffe (git master as of right now) compiles cleanly against the libprotobuf-dev-2.5.0-9ubuntu1 which is in ubuntu 14.04LTS.
I guess before you get this problem, you have used protoc to generate caffe.pb.h`. If you did, my solution maybe be useful to you.
Firstly, you should know how many protoc installed in your OS.
For example, in my OS:
Prompt> whereis protoc
protoc: /usr/bin/protoc /home/xxx/.conda/envs/python27/bin/protoc/usr/share/man/man1/protoc.1.gz
So, there are 2 protoc in my OS. You can use which protoc and protoc --version in order to find which version protoc is used default. In my OS:
Prompt> which protoc
/home/xxx/.conda/envs/python27/bin/protoc
Prompt>protoc --version
libprotoc 3.5.1
Finally, use another protoc to create caffe.pb.h again.
let the dir to caffe/src/caffe/proto, and execute:
/usr/bin/protoc --cpp_out=. caffe.proto
I solved this on my computer and maybe it can help you. My environment is Ubuntu16.04, and I installed Anaconda(for python2.7) before I install Caffe. It happens that I used conda to install libprotobuf-dev, and this leads to conflict with the caffe's 'sudo apt-get install libprotobuf-dev' command, for 'apt-get' and conda installed different on my computer which can be find by 'locate protobuf', so I remove the Anaconda's version of libprotobuf, and no problem happens again.
conda uninstall libprotobuf
When you install tensorflow before install Caffe, this problem will also happen, because of the libprotobuf conflict.
I solve the problem by
conda uninstall libprotobuf
then remove the caffe folder and download a new one
git clone https://github.com/BVLC/caffe.git
then do
make all -j8
I'm currently getting an error which points me to these lines in the header file produced by protoc:
#if 2006001 < GOOGLE_PROTOBUF_MIN_PROTOC_VERSION
#error This file was generated by an older version of protoc which is
#error incompatible with your Protocol Buffer headers. Please
#error regenerate this file with a newer version of protoc.
#endif
But my protoc version matches the one above:
protoc --version
libprotoc 2.6.1
What am I doing wrong?
Originally my protoc version was 3.0.0 then reinstalled it by syncing back to 2.6.1 and doing the steps; make distclean, ./configure , make, make install to install the desired 2.6.1 version. I needed the older version since that's the one installed in our servers.
The problem is that the installed headers on your system (in /usr/include/google/protobuf or /usr/local/include/google/protobuf) are from a newer version of Protocol Buffers than your protoc. It may be the case that you have both versions installed in different locations, and the wrong one is being used.
But my protoc version matches the one above:
Yes, because that code was generated by your protoc, and it knows its own version. The code is asking: "Is my version (2006001) less than the minimum version which the installed headers claim is required (GOOGLE_PROTOBUF_MIN_PROTOC_VERSION)?"
I am having trouble compiling my program which uses libcurl.
The environment I am using is CentOS 6.6 on a VM, and I am getting errors which suggests that the library has either:
not installed correctly or
cannot be found.
I did a
sudo yum install libcurl followed by a
sudo yum install libcurl-devel followed by a
sudo yum update
It seems that the curl.h has been put under /usr/include/curl which seems correct so I am unsure as to why this has occurred.
It is worth noting that a test program with #include <curl/curl.h> is compiling.
Also, when libcurl-devel is not installed (and only libcurl is),
gcc complained it couldn't find curl.h, as expected,
there was also no curl directory under /usr/include/, as expected,
however libcurl did install a curl file under /usr/bin/, as expected.
In Ubuntu I only had to install libcurl-openssl
Some example gcc errors:
$gcc new.c -lcurl
new.c: In function ‘main’:
new.c:74: error: ‘CURLOPT_MAIL_FROM’ undeclared (first use in this function)
new.c:74: error: (Each undeclared identifier is reported only once
new.c:74: error: for each function it appears in.)
new.c:81: error: ‘CURLOPT_MAIL_RCPT’ undeclared (first use in this function)
If you are installing libcurl-devel from the CentOS RPM then it absolutely should not be putting the header, or anything else, in /usr/local/curl. /usr/local is for locally-built components, not for components provided by the OS. Exactly what that means can be a subject for debate, but I can confirm that the CentOS 6 RPM for libcurl-devel installs the headers in /usr/include/curl.
With that being the case, if CentOS's libcurl-devel is installed, then you shouldn't need any special compiler flags to get the compiler to resolve
#include <curl/curl.h>
correctly, but if you happen to have a different curl.h somewhere on your system then you could cause it to be chosen instead. Still, although I could maybe believe the compiler finding /usr/local/include/curl/curl.h automatically (that is, without -I/usr/local/include), I would be very surprised to hear that it finds /usr/local/curl/curl.h automatically.
But that probably isn't your problem. CentOS 6 provides version 7.19 of libcurl. That version does not provide the macros you are trying to use, at least not in libcurl-devel. I have checked for a possible add-on package corresponding to Ubuntu's libcurl-openssl, but there is no CentOS 6 package (or EPEL/el6 package) that has both "curl" and "ssl" in its name.
If you can identify what minimum version of libcurl you need, you can probably build it yourself. In such cases I prefer to take a source RPM from Fedora's Koji system, build RPMs from it on the local system, and install them (possibly updating existing RPMs in the process). Alternatively, you can probably build and use a private copy, but in that case you will want to link it statically into your program.