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.
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 can't get a cross compiled build running on my Raspberry Pi 1 B+. The error I keep getting is:
ImportError: /usr/lib/arm-linux-gnueabihf/libstdc++.so.6: version 'CXXABI_1.3.11'
not found. I tried multiple compilers with different settings but I keep getting the same error. Also changing the LD_LIBRARY_PATH to the location of libstdc++ on my Pi didn't work. Today I got a sort of breakthrough finding out that the make process outputs "will change in GCC 7.1" after an argument. I'm not a hundred percent sure that this is what cause the error, but GCC 7.1 comes with version 1.3.11 of CXXABI, so I suspect it to be the cause. Is there anybody that knows how to stop this from happening? I'm building on a VM with Ubuntu 17.10. I'm building using sh autogen.sh; ./configure --host=arm-linux-gnueabihf; make -j8
Thanks
Edit: Found the solution myself, it was: export CXX=/path/to/toolchain/arm-linux-gnueabihf-g++
Your cross-GCC comes with a version of libstdc++.so which is not compatible with the one installed on your system. You can either run compiled program with modified LD_LIBRARY_PATH (or -Wl,-rpath), pointing to directory with cross-compiler's libstdc++.so, or downgrade your cross-compiler to match your distro.
This is related to this question: Can't install Vision Workbench.
I need to install boost1.42 in order to compile Vision workbench. I have downloaded the 1.42 package http://sourceforge.net/projects/boost/files/boost/1.42.0/ and extracted it. First I run ./bootstrap.sh --prefix=/home/myname/ and then ./bjam install. Everything works fine except for
error: #error "Threading support unavaliable: it has been explicitly disabled with BOOST_DISABLE_THREADS"
So the thread package is not installed correctly and that means I cannot generate a make-file for Vision Workbench.
Does anyone have an idea of how to solve it?
/ Erik
As per the instructions http://www.boost.org/doc/libs/1_42_0/more/getting_started/unix-variants.html
$ cd ~/boost_1_42_0
$ bjam --build-dir=/tmp/build-boost toolset=gcc stage
should build static and shared non-debug multi-threaded variants of the libraries. To build all variants, pass the additional option, “--build-type=complete”.
If this doesn't work for you, then potentially your toolset is not being detected correctly (try specifying it). This is not unlikely since Boost 1.42.0 is really old, and probably could never know about the compiler version you're using.
As an aside, the BOOST_DISABLE_THREADS is known to make no difference for recent boost version.
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.
I've gone to http://sourceforge.net/project/showfiles.php?group_id=2435, downloaded the Automated MinGW Installer for MinGW 5.1.4 and at the same time the GNU Source-Level Debugger Release Candidate: GDB 6.8-3. I've then installed MinGW base tools into C:\MinGW. No problem so far.
However when I come to install the gdb debugger it has a lot of files and folders with the same names as some already installed but the files are different to those already installed. e.g C:\MinGW\include\bfd.h is 171 KB but gdb-6.8-mingw-3\include\bfd.h is 184 KB.
How do I add gdb to MinGW without breaking what's already installed?
In a command prompt I browsed to C:\MinGW\bin and ran:
mingw-get.exe install gdb
That fixed it for me. Not sure if it matters but I have C:\MinGW\bin in my path (guess I probably didn't need to browse to C:\MinGW\bin).
The Current Release (5.2.1) version of gdb at the project files page has always worked for me. The download is a stand-alone .exe, you don't need anything else.
But I'll bet the .exe in the 6.8 package will work, too. I'd try using just the .exe, and then if there are problems, try extracting the other files from the 6.8 package. (Though that may cause problems with the rest of the MinGW installation.)
Update: There seems to be a 7.something version. I haven't tested it thoroughly, but it seems to work, even with gcc 3.
Get Wascana Desktop Developer. It combines MinGW, gcc, Eclipse and gdb in one package.
You can safely overwrite the files prepackaged with MinGW with the (newer) ones from the gdb tarball. You can also choose not to overwrite them - just make sure to pick either one set, i.e. avoid mixing files from the older and the newer package.
Most of the offending files are probably not really relevant to you anyway. For example, the files belonging to the libbfd library aren't required for gdb's day to day operation, they're used if you want to extend the debugger or write debugging tools yourself.
At any rate, make a backup of the mingw directory before untarring the new release. It's very easy since MinGW is self-contained in that directory. That way, if anything should malfunction, you can just delete the directory and restore from the backup.
Usually for installing gdb in windows, You have to 2 ways to install:
1) use ready-made binaries that were build and compiled from GNU gdb by some provider (easy to install)
use TDM-GCC binaries provided from the following URL and that is including inturn the gcc complier and also gdb debugger.
http://tdm-gcc.tdragon.net/
use Equation package inside which GNU GDB was already compiled and built.
http://www.equation.com/servlet/equation.cmd?fa=gdb
2) use minimal mingw or cygwin package then after install gdb inside it.
Install either mingw or cygwin inside which GDB is already shipped
Open cygwin or mingw terminal and just type the following to make sure it is already installed
$ gdb --version
Hint: if you did not find gdb installed, simply open the cygwin or mingw package installer and make sure you already check gdb
Hint: getting and installing a debug build of the OHRRPGCE is providing useful information about crashes.
From cygwin or mingw terminal, Start gdb using the following
c:\mingw\bin\gdb.exe program_to_debug.exe
REF: http://rpg.hamsterrepublic.com/ohrrpgce/GDB_on_Windows
The TDM GCC/MinGW32 builds installer includes gdb. It's gcc 4.4.x with all the core binary packages required for basic Windows development, and is widely used without any unusual problems.