When I copy my executable and lib dependencies to another computer and run the program I get this error:
This program was compiled against version 2.6.1 of the Protocol Buffer runtime library, which is not compatible with the installed version (3.5.0). Contact the program author for an update. If you compiled the program yourself, make sure that your headers are from the same version of Protocol Buffers as your link-time library.
This error only happens in the new computer. I can run my program on my computer without any issue.
I tried to check with ldd -d and objdump -p engine | grep NEEDED which of the libs are that have protobuf in them, but I can't find them.
My program uses: opencv with Cuda, boost, tensorflow, tensorRT.
Both of the computer OS is Ubuntu 16.04.6 LTS.
How can I find which part has the issue with this conflict?
I tried to recompile opencv without protobuf by adding -DBUILD_PROTOBUF=OFF -DPROTOBUF_UPDATE_FILES=ON -DPROTOBUF_INCLUDE_DIR=/usr/include -DPROTOBUF_LIBRARY=/usr/lib/x86_64-linux-gnu/libprotobuf.so.
This did not solve the issue.
You have two different version libprotobuf, with one installed in /usr/local/lib/ by dynamic library.
But when you build your program, you include other version of libprotobuf.
You can reinstall libprotobuf to solve this question.
If you install libprotobuf from source, make sure you added the flag -Dprotobuf_BUILD_SHARED_LIBS=ON.
Related
I compiled a copy of codes on one PC by Intel Fortran with the Lapack library. And then I ran it on another PC (the same OS without having Lapack installed). It failed.
This can be solved by installing Lapack on the other PC. The same problem occurs when using other libraries. This looks like a dynamical compiling issue (I am not sure). My question is how to get a real executable file that can be run on any machine?
I get a quite clear answer now. The direct answer to the question is (as #Vladimir F mentioned & #Ross) use option "-static" for both gfortran and ifort.
Some possibly occurred problems.
The libs for static compiling and dynamical compiling are different. For instance, we may have installed a lib called "LIBNAME" already. However, a similar lib called "LIBNAME-static" may be needed for the "-static" option version. According to the warning of something like:
/usr/bin/ld: cannot find -lLIBNAME
what we need to installed is libLIBNAME. We can install it (Fedora for instance) by
sudo dnf install libLIBNAME.
And
sudo dnf install libLIBNAME-static
may also needed. Just try them.
I'm trying to install octave 3.8.1 on a cluster running Redhat+IBM LSF. I don't have write access to any directory except my home dir. I have loaded three modules 1) pcre 8.33 2) blas 08/2013 3) lapack 3.5.0. But when I run ./configure, I got the error "configure: error: A BLAS library was detected but found incompatible with your Fortran 77 compiler settings.", as the image below shows.
I have tried loading module gfortran64 and add F77=gfortran as command line parameter, but this doesn't work. Could you please help me with this problem? If you need any information please tell me in this webpage. Thank you.
I've had the same problem. On a fresh install of CentOS 6.3 I was able to compile octave 4.0.0 successfully.
After installing the necessary dependencies (notably blas, lapack and pcre) I created symlinks to liblapack and libblas in some directory, e.g.:
mkdir /some/path
cd /some/path
ln -s /usr/lib64/libblas.so.3 libblas.so
ln -s /usr/lib64/liblapack.so.3 liblapack.so
Then put the relevant directory in LDFLAGS, e.g., in bash/sh:
LDFLAGS=-L/some/path ./configure
So either octave's configure didn't look in /usr/lib64, or it requires the name of the libraries to end in ".so" (not ".so.3"). I haven't investigated which of the two was the problem since the above worked for me.
/some/path can be deleted when octave has been installed.
My octave repository was compiling flawlessly, until the day I installed gfortran and started to get the same message. I had been using f77 (from the fort77 package). Somehow, the configure script defaulted to gfortran, which [I believe] is incompatible with the BLAS libraries.
I would suggest using f77 in octave compilation instead of gfortran.
I compiled octave 4.0.0 on Mint 17.1, but I believe the issue is the same.
I'm building a large C++ project using cmake on ubuntu 12.04 and then taking the resulting binary package and trying to run it on ubuntu 11.04. However the program fails saying it needs glibc version 2.14 but can only find up to version 2.13.
How can I find out exactly why glibc=>2.14 is required?
Unlike most libraries, glibc versions its symbols. Every symbol is tagged with a value (e.g. "GLIBC_2.3.4") representing the version of the library where it's interface was last changed. This allows the library to contain more than one version of a given symbol and support binaries compiled against older versions while preserving the ability to evolve. You can see this detail with objdump -T /lib/libc.so.6.
Basically, something in your app was linked against a symbol that was changed since 11.04. Try objdump -T on your binary and see what tags it's looking for.
But broadly, backwards compatibility doesn't work like that in Linux. If you want something to run on older software, you should build it on older software. It's possible to set up a backwards-compatible toolchain on more recent distros, but it's not the default.
When you build your C++ project, it will link to the version of the glibc library on your 12.04 installation. What are the linker options in your build command?
Without knowing exactly what you are building, I'd say you might be better off building on 11.04 and then running on 12.04.
I develop a CGI C++ application that I compiled under Debian. Running this app on an Ubuntu system I am getting the error:
relocation error: /lib32/libresolv.so.2: symbol strlen, version GLIBC_2.0 not defined in file libc.so.6 with link time reference
What can I do now? Should I recomile on the Ubunto system? Can I replace a library?
Edit
I link my application with -static.
Running the command ldd --version on the Ubuntu system showed my that EGLIB is used there.
What this error means is that your program was compiled/linked against an older version of GNU libc, which is not supported on the system where you want to run your executable.
You have few options to solve it:
Make sure you use the same or compatible version of libc when compiling and running.
Link against a static runtime.
Install older version of libc on Ubuntu system to match the Debian's environment.
I am trying to compile a 32-bit version (MinGW) of a program I wrote using zlib. Until now, I've never has to compile for 32-bit so the version of zlib I compiled from source (libz.a) is 64-bit. I tried to rerun the makefile in the zlib-1.2.5 directory but it only compiles a 64bit version of libz.a.
I can't seem to find an option to build 32-bit.
Does anyone know how to do this?
Thanks!
Jeffrey Kevin Pry
Checking the configure file, you can see some env.
On 64bit debian, following command line will build the 32bit version of libz
CFLAGS=-m32 ./configure
It turns out I had to get the 32bit version of MinGW and compile it with that. I was using MinGW64.
Using CFLAGS=-32 won't do it for me, configure script still shouts out telling me to use win32/Makefile.gcc instead all the time.
The recent version of zlib is 1.2.11, so it should be minimal gap of difference up until today. Without any context on system, the following might be useful for other users facing this similar problem these days.
I cross compile on Linux (Ubuntu 18.04), and target 32-bit version of zlib to be produced. What I did is as follows.
./configure (this is just to let us have required file to building process, we will be using different Makefile though)
Modify win32/Makefile.gcc for its PREFIX=i686-w64-mingw32- (for 64-bit you change it to PREFIX=x86_64-w64-mingw32-.
make -fwin32/Makefile.gcc
Install to your desire location via make install -fwin32/Makefile.gcc SHARED_MODE=1 INCLUDE_PATH=/tmp/zlib-win32/include LIBRARY_PATH=/tmp/zlib-win32/lib BINARY_PATH=/tmp/zlib-win32/bin. Notice that you need to specify INCLUDE_PATH, LIBRARY_PATH, and BINARY_PATH. BINARY_PATH will contains result .dll file.