I am using SQLite 3 for Database management in my ARM9 based microprocessor.
I want to cross compile the latest version of the SQLite 3 for my project in Linux (Ubuntu 10.04). I am using the arm-none-linux-gnueabi-gcc compiler for development.
I tried to cross compile using following commands,
Downloaded the sqlite-amalgamation-3.7.0.tar
I extract it and then write the following command on Terminal,
sudo ./configure --exec-prefix=/media/8CCC8E9BCC8E7F68/SQLIte3/sqliteinstall/ --host=arm --target=arm CC=/opt/arm-2011.03/bin/arm-none-linux-gnueabi-gcc AR=/opt/arm-2011.03/bin/arm-none-linux-gnueabi-ar STRIP=/opt/arm-2011.03/bin/arm-none-linux-gnueabi-strip RANLIB=/opt/arm-2011.03/bin/arm-none-linux-gnueabi-ranlib CFLAGS="-Os"
It successfully cross compiled the SQLite.
Then,
sudo make command.
It successfully run.
Now "make install " command.
It did not give me an error but when i went to the config.log file i found there is some sentences as following,
1.conftest.c:17:7: error: size of array 'off_t_is_large' is negative
2.conftest.c:12:28: fatal error: ac_nonexistent.h: No such file or directory
compilation terminated.
3.conftest.cpp:23:28: error: ac_nonexistent.h: No such file or directory
4.conftest.c:67:13: error: invalid type argument of unary '*' (have 'int')
I doubt that weather it has been cross compiled properly or not.
I can not understand.
I inserted the library on my board it works fine but the problem is that the speed got very slow. I think there is some problem that i have not set any flags for the GCC compiler.
I could not find any options.How I can set the particular flags for the GCC compiler so that unnecessary features can be omitted.
You probably shouldn't try to do cross-compilation manually. Instead, use an embedded Linux build system that will do that for you, and automate the cross-compilation process entirely. My favourite is of course Buildroot (http://buildroot.org), but there are plenty of others (with varying levels of quality, complexity and features) : OpenEmbedded, Yocto, PTXdist, etc.
Related
Background: I compile bitcoind on one system but run it on another. When I compiled bitcoind 0.19.1 some time back using the following method, I was able to run bitcoind and bitcoin-cli on the target system without issue. I think.
./autogen.sh
./configure --disable-wallet --disable-tests --disable-bench --disable-gui --enable-util-tx=no --prefix=$HOME/bitcoind/x64 --exec-prefix=$HOME/bitcoind/x64
make && make install
Today I compiled v0.20.0 using the same method. If I run ./bitcoind -version on the system I compiled the binary it runs fine, but if I take the binary to my target system I get the following error:
./bitcoind: error while loading shared libraries: libboost_filesystem.so.1.67.0: cannot open shared object file: No such file or directory
The binary seemed to be portable last time, and the pre-compiled binary I download from the Bitcoin Core team runs fine.
Note that on the target system libboost-filesystem-dev and libboost-filesystem1.67-dev are not installed, this is likely the source of my error. That said, running the pre-compiled binary from the Core team runs, so why doesn't mine?
Can someone help me understand if I did something wrong or if I need to add ./configure flags to make the binary more portable? Specifically what I likely did differently than the core developers that made my binary fail where theirs worked?
EDIT 1: Running ./configure --enable-static or ./configure LDFLAGS=-static does not result in a portable binary either.
Also note that installing libboost-filesystem library with apt does fix the error.
Thanks to Andrew Chow for his helpful answer to this on the bitcoind StackExchange. I needed to build the depends as per the depends documentation. Since I'm building for the same platform I'll be running on, I can run make in the depends directory with no arguments except -j2 which uses two cores. Change the number to however many cores you want to commit to the compile.
cd depends
make -j2
cd ..
./autogen.sh
./configure --prefix=$PWD/depends/x86_64-pc-linux-gnu
make -j2 && make install
I'm trying to set up pocl-0.11 on an ARM (llvm-3.3). I used ./configure --enable-debug --disable-icd --enable-testsuites=all (I'd like to get pocl to run without ICD loader as a first step).
During configure I got a couple of warnings about disabled tests due to missing glut, libDSL, boostlib, etc. Since the warnings 'only' concern some testsuites, I assume the configure is fine and I guess some basic tests will still be enabled!?
Furthermore I get the output:
checking LLC host CPU... cortex-a9
configure: using the ARM optimized kernel lib for the native device
<stdin>:1:19: error: 'test' declared as an array with a negative size
constant int test[sizeof(long)==8?1:-1]={1}; (Is that relevant? I don't really know what to do with this message.)
Eventually configure succeeds and make & make install run without any hint of a problem.
make check then fails all tests, even: check for pocl version FAILED (testsuite.at:29)
The 001/testsuite.log file indicates a linker problem!?
Do you have any idea?
Am I missing a configure flag or an environment variable? I didn't touch --prefix or any other paths.
LLVM 3.3 is quite old and its support will be dropped after the next pocl release. The configure error message you see probably means it fails to detect your CPU features correctly, but the testsuite error indicates that not all LLVM symbols are properly linked in. You can try fixing this by using a shared LLVM library, but I really suggest you to upgrade LLVM. The upcoming 3.7 should work now and has fixed several issues and includes better OpenCL C Clang support.
When compiling with -fsanitize=memory I get WARNING: Trying to symbolize code, but external symbolizer is not initialized! when running the program. How do I initialize the external symbolizer?
I solved my own problem using MSAN_SYMBOLIZER_PATH=$(which llvm-symbolizer-3.4) ./a.out. The problem is that Ubuntu postfixes the version number but the binary doesn't know that. Of course you need to use MSAN instead of ASAN when using the memory sanitizer.
You are supposed to be able to set the ASAN_FILTER environment variable to point at a symbolizer, but I could not get it to work. However, you can redirect stderr into a symbolizer after the fact. You'll still get the warnings about the uninitialized symbolizer, but the filenames and line numbers will be correct.
You can use asan_symbolizer.py as the external symbolizer. After downloading it from that link (to /tmp, for example), invoke your program like so (in bash, for this example):
./myprogram 2>&1 | /tmp/asan_symbolize.py | c++filt
On my Ubuntu system, the issue is that LLVM's tools are installed under /usr/bin with version suffixes (like llvm-symbolizer-4.0), and the sanitizer tools are looking for them without version suffixes.
LLVM also installs its binaries to, e.g., /usr/lib/llvm-4.0/bin; the tools under /usr/bin are actually just symlinks. So an easy solution is to add the appropriate /usr/lib/llvm-*/bin directory to your path when working with sanitizers.
I received such warning when I run program debug version (compiled with -fsanitize=address) on Linux machine that didn't contain clang installation. The problem disappeared after I installed clang from devtoolset.
So I am trying to install a program on my windows machine that required me to install Cygwin to install it. So I am working from a README file and assueme I have compiled the code previously correctly (its one line sh build.sh) and when actually trying to use the program I get the following error:
BabakP#Babak /cygdrive/c/Users/BabakP/Desktop/test
$ ./Runlock input.tst output.tst 1
./Ostrich: Exec format error. Binary file not executable.
I guess I am trying to figure out why I am getting this error so any suggestions on how to troubleshoot it would be great!
./Ostrich is a Mac executable. It can't be executed under Cygwin. (A MacOS emulator that runs under Windows or Cygwin is theoretically possible, but I don't know of any such thing.)
Without knowing the details of the software you're trying to install, it's hard to say how or whether you can fix it.
You may be able to rebuild Ostrich from source (if you have the source, and if it's not MacOS-specfic).
I am trying to compile Qt 4.7.3 on mignw32 using gcc 4.6.0.
I get the following error when running ./configure:
In file included from C:/work/qt-gcc-4.6.0/include/QtCore/private/qcore_unix_p.h:1:0,
from C:/work/qt-gcc-4.6.0/src/corelib/io/qfsfileengine_unix.cpp:45:
C:/work/qt-gcc-4.6.0/include/QtCore/private/../../../src/corelib/kernel/qcore_unix_p.h:59:3: error: #error "qcore_unix_p.h included on a non-Unix system"
The weird thing is that I am running Windows 7, and it is trying to include that.
Also in the Makefile it is using qfsfileengine_unix and qfsfileengine_iterator_unix instead of qfsfileengine_win and qfsfileengine_iterator_win.
If I change the Makefile to use the Windows' ones, I get the following error (the file does not exist):
In file included from C:/work/qt-gcc-4.6.0/include/QtCore/../../src/corelib/global/qglobal.h:62:0,
from C:/work/qt-gcc-4.6.0/include/QtCore/qglobal.h:1,
from C:/work/qt-gcc-4.6.0/mkspecs/win32-g++/qplatformdefs.h:53,
from C:/work/qt-gcc-4.6.0/src/corelib/io/qfsfileengine_win.cpp:43:
C:/work/qt-gcc-4.6.0/include/QtCore/qconfig.h:1:46: fatal error: ../../src/corelib/global/qconfig.h: No such file or directory
compilation terminated.
When compiling /qt/src/corelib/io/qfsfileengine_win.cpp
Suggestions?
Try ./configure --help
There is probably a flag for a ms-windows, x86 compilation.
It might be something like:
./configure --target-os=mingw32
Keep in mind -- the os parameter name might be different, and the selectable target values *might be different* -- with scripts from different authors -- some values you might encounter might be 'win32', 'win32-386', 'x86-windows32', etc.
See if
./configure --help
Won't give you a list...
You can also redirect its output to a file for easy reading in your favorite editor,
./configure --help > myconfighelp.txt
Good luck!