I compiled gcc on one of my ubuntu 10.10 hosts, and installed it in /c. I can compile c and c++ programs fine on that host but when i copy /c (which contains bin, libexec etc) to a ubuntu 10.04.2 host i get:
/c/libexec/gcc/i686-pc-linux-gnu/4.5.2/cc1: error while loading shared libraries: libmpc.so.2: cannot open shared object file: No such file or directory
when compiling a simple .c file.
I've also installed and compiled gmp, mpfr and mpc from source (same versions as i did on the 10.10 host) but it's still coming up with the same error.
The reason i'm not recompiling gcc on each host is because it takes too long, and prefer not to use the gcc (from the build-essential) deb that comes with ubuntu
Please help
did you export your LD_LIBRARY_PATH environment variable? Looking at the error, it's not able to find libmpc.so.2.
Try 'locate libmpc.so.2' and if you can find that,
export LD_LIBRARY_PATH=
Here are some details on how to set LD_LIBRARY_PATH in Ubuntu:
https://help.ubuntu.com/community/EnvironmentVariables#File-location%20related%20variables
Related
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.
I would like to distribute C++ binary that is created by using Eclipse ++ IDE, with the following settings:
Cross GCC Compiler: gcc -std=c++17
Cross G++ Compiler: g++ -std=c++17
Tool Chain settings:
Cross GCC Compiler
Cross G++ Compiler
Cross GCC Linker
Cross G++ Linker
Cross GCC Archiver
Cross GCC Assembler
I am compiling with boost::serilization and have connect that in Linker. The binary is created on Ubuntu 16.04. I tried to run the binary on Ubuntu 14.04, and it give the error:
error while loading shared libraries: libboost_serialization.so.1.58.0: cannot open shared object file: No such file or directory.
I have also installed libboost on the system by using
sudo apt-get install libboost-program-options-dev
But, it gives me the same error.
I think with the above Eclipse IDE setting, it should work in most of the Linux platforms. Is my presumption of its working on most of the Linux platforms wrong??.
When you build your program you link it with specific versions of the shared libraries. On older releases of e.g. Ubuntu those newer versions of the libraries doesn't exist.
If you want to copy the executable between different systems you need to link statically. That means all libraries are linked into the executable so it doesn't rely on shared libraries. It will make the executable bigger of course.
When compiling my binary (addon for node.js) on Ubuntu 13.10. then the linker takes libudev.so.1 to link.
Then I copy the binary to a Ubuntu 12.04 machine and run the binary. Then there is an error that libudev.so.1 can't be found. On Ubuntu 12.04 is libudev.so.0 installed.
I provide gcc with the param -ludev
The binary expects libudev.so.1. I checked it with this command:
$> strings bin | grep udev
$> ...
$> libudev.so.1
How can I tell the linker it should take any provided libudev version of the OS. So the binary would require something like libudev.so*.
In the magical Linux world it is very difficult to compile and link on one machine and then copy the binary to another machine and run it there. There are a lot of variations, as you have also experienced not all aer compatible with each other, so this make the porting of binaries very difficult, if not altogether impossible. It might work with some setups, and not with others. Now you have two possibilities:
I assume, your 12.04 is a production environment so you cannot do whatever you want... So, in this case create an identical (virtual) machine to the Ubuntu 12.04 compile and link on it. Copy the executable to the 12.04 you need to run on it. Chances are that it will work without problems.
If the assumption about the production environment is not true, then install the compilers and necessary environment and compile the source on the remote machine. This way you will know it will work all the time on that machine.
In your 12.04 find out at which location libudev.so.0 is there. then make a symbolic link to that library with libudev.so.1 and see.
To make symbolic link:
ln -sf /opt/lib/libudev.so.1 /opt/lib/libudev.so.0
I have a C++ package that I run it on my machine (Ubuntu 11.10 OS type:32 bit) and everything is perfect. When I try to run it on a Linux server (Ubuntu 12.04.2 LTS (GNU/Linux 3.2.0-39-generic x86_64)), I will get this error:
error while loading shared libraries: libstdc++.so.6: cannot open shared object file: No such file or directory
I do not know where is the problem. Hopefully you can help me.
The different machines have different versions of the standard library installed. Since the required dynamic library version is hardcoded into the binary, you can either recompile your program on the target machine, or link the standard library statically with -static-libstdc++.
(This is ignoring any 32-bit vs 64-bit issues; presumably you'll need 32-bit libraries on your 64-bit machine if you want to use 32-bit binaries.)
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.