I would like to generate MIPS binaries using gcc on an x86 machine. In order to install MIPS cross-compiler I followed the directions on this page. I could install gcc and binutils successfully. I tried to to compile a simple hello world program using the cross compiler.
/opt/cross/bin/mipsel-unknown-linux-gnu-gcc -mips1 hi.c
I got the following error.
/opt/cross/lib/gcc/mipsel-unknown-linux-gnu/4.8.2/../../../../mipsel-unknown-linux-gnu/bin/ld: cannot find crt1.o: No such file or directory
/opt/cross/lib/gcc/mipsel-unknown-linux-gnu/4.8.2/../../../../mipsel-unknown-linux-gnu/bin/ld: cannot find crti.o: No such file or directory
/opt/cross/lib/gcc/mipsel-unknown-linux-gnu/4.8.2/../../../../mipsel-unknown-linux-gnu/bin/ld: cannot find -lc
/opt/cross/lib/gcc/mipsel-unknown-linux-gnu/4.8.2/../../../../mipsel-unknown-linux-gnu/bin/ld: cannot find crtn.o: No such file or directory
collect2: error: ld returned 1 exit status
I did some research online to figure out what the problem was, and changed the command I used to the following.
/opt/cross/bin/mipsel-unknown-linux-gnu-gcc -B/usr/lib/i386-linux-gnu -mips1 hi.c
Now I get this error message:
/opt/cross/lib/gcc/mipsel-unknown-linux-gnu/4.8.2/../../../../mipsel-unknown-linux-gnu/bin/ld: /usr/lib/i386-linux-gnu/crt1.o: Relocations in generic ELF (EM: 3)
/usr/lib/i386-linux-gnu/crt1.o: error adding symbols: File in wrong format
collect2: error: ld returned 1 exit status
I am not sure what the problem is. The only thing I can think of is the "--without-headers" option passed to configure program when building gcc. Configure command for gcc given on the linux-mips page is as below.
% ../gcc-3.8.2/configure --target=$TARGET --prefix=$PREFIX \
--enable-languages=c --without-headers \
--with-gnu-ld --with-gnu-as \
--disable-shared --disable-threads \
--disable-libmudflap --disable-libgomp \
--disable-libssp --disable-libquadmath \
--disable-libatomic
I would appreciate some help. The system on which I generated the cross compiler uses gcc4.7.2-5. I used the sources for gcc-4.8.2 and binutils-2.24 to generate the cross compiler.
/opt/cross/bin/mipsel-unknown-linux-gnu-gcc -mips1 hi.c
Add a SYSROOT to the compile command. It should look similar to:
/opt/cross/bin/mipsel-unknown-linux-gnu-gcc -mips1 --sysroot=/opt/cross/... hi.c
The SYSROOT will provide the header and library path automatically (rather than adding -I and -L individually).
You will know when you have a SYSROOT because there will be a bin/, include/ and lib/ in the path used. For example, here's a SYSROOT for arm-linux-gnueabi (i.e., arm-linux-gnueabi-gcc and arm-linux-gnueabi-g++):
$ ls /usr/arm-linux-gnueabi
bin include lib
So, in this example, you would use --sysroot=/usr/arm-linux-gnueabi.
If you need help with locating a SYSROOT, then perform a find:
$ find /usr -name crt1.o
/usr/arm-linux-gnueabi/lib/crt1.o
/usr/lib/debug/usr/lib/x86_64-linux-gnu/crt1.o
/usr/lib/x86_64-linux-gnu/crt1.o
In your case, you would probably search from /opt/cross. Obviously, you would want the one for the target (arm-linux-gnueabi), and not the ones for the host (x86_64-linux-gnu).
Adding --sysroot= would resolve this issue.
As you are cross-compiling you shouldn't select just any other folder which has crt1.o or crtX.o as your sysroot directory. It could be your host-machine's files. (Which if you are running on a x86, it would be for x86). Again it varies from 32bit and 64bit.
With newer version's of GCC toolchain, you need to have a sdk part of it which has the appropriate sysroot and crt1.o. This should go with your ABI and your target architecture.
Related
I am trying to cross compile libpng for RaspberryPi on Ubuntu 14.04 (x_64) with zlib
but configure fails with
configure:11400: arm-linux-gnueabihf-gcc -o conftest -g -O2 -I/home/user/RPI_DEV/lib/include conftest.c -lz -lm >&5
/home/user/RPI_DEV/xtools/arm-bcm2708/gcc-linaro-arm-linux-gnueabihf-raspbian-x64/bin/../lib/gcc/arm-linux-gnueabihf/4.8.3/../../../../arm-linux-gnueabihf/bin/ld: cannot find -lz
collect2: error: ld returned 1 exit status
configure:11400: $? = 1
configure: failed program was:
....
Because I am using toolchain for arm, arm-ld cant find zlib.
Is there any option for configure not to compile with shared lib but to try with static lib (eg. -static -lz).
Command is
./configure --enable-static=true --enable-shared=false --with-zlib-include="/home/user/RPI_DEV/lib/include" --with-zlib-lib="/home/user/RPI_DEV/lib/lib" LDFLGS="-L/home/user/RPI_DEV/lib/lib" CPPFLAGS="-I/home/user/RPI_DEV/lib/include" -enable-static --host=arm-linux-gnueabihf --prefix=/home/user/RPI_DEV/lib --exec-prefix=/home/user/RPI_DEV/lib
You need to cross build and install zlib into your toolchain before trying to use it in another project.
What you are doing might work but only if you spell LDFLAGS correctly:
LDFLGS="-L/home/user/RPI_DEV/lib/lib"
Note the missing 'A'. I don't know why your second attempt worked, given you had the same misspelling; possibly you had a correct LDFLAGS in your environment?
Anyway there should be a Ubuntu cross-development guide somewhere that explains how to do this. It's slightly off topic but for Gentoo you use 'crossdev' to install the toolchain then a crossdev specific version of the normal package installation mechanism ([host]-emerge) to install zlib into the toolchain.
Also, the arguments --with-zlib-include and --with-zlib-lib are not supported by any current version of libpng I can find. If you are cross-compiling libpng for an RPi (or, indeed, any ARM system) you should be using the latest version of 1.6 that you can find.
Unless someone solves this the RIGHT way, this is hack I've done.
Open configure.ac file
Find and comment out line
AC_CHECK_LIB(z, zlibVersion, , AC_ERROR([zlib not installed]))
Configure will pass wihout check for zlib and then add zlib by hand
LDFLGS="-L/home/user/RPI_DEV/lib/lib -L/home/user/RPI_DEV/lib/lib/libz.a"
Run autoconf
Run ./configure ...
I'm trying to build my own library. It worked on x86 linux so I wanna build for MIPS Linux (Little endian.)
I'm using sourcery codebench in Mento Graphics and buildroot and CMake.
I configured build_all.sh like below.
#!/bin/bash -ev
export TARGETROOT="/usr/mipsel-buildroot-linux-gnu/sysroot"
mkdir -p mips_build
cd mips_build
cmake -DCMAKE_SYSTEM_NAME="Linux" \
-DCMAKE_C_COMPILER="${CROSS_COMPILE}gcc" \
-DCMAKE_CXX_COMPILER="${CROSS_COMPILE}g++" \
-DCMAKE_AR="${CROSS_COMPILE}ar" \
-DCMAKE_C_FLAGS="-EL -c -g -O2 -fPIC --sysroot=$TARGETROOT " \
-DCMAKE_CXX_FLAGS="-EL -c -g -O2 -fPIC --sysroot=$TARGETROOT " \
../
make
cd ..
Where $CROSS_COMPILE=/home/vagrant/bd1/mips-2014.05/bin/mips-linux-gnu-
And CMakeFiles.txt is like below.
make_minimum_required (VERSION 2.6)
set(EMSG_INCLUDE_DIR ${CMAKE_CURRENT_SOURCE_DIR}/../../src/eagle_msg/include )
set(EMSG_LIB_DIR ${CMAKE_CURRENT_SOURCE_DIR}/../../lib )
set (PROJECT_SOURCE_DIR ${CMAKE_CURRENT_SOURCE_DIR}/src)
set (PROJECT_INCLUDE_DIR ${CMAKE_CURRENT_SOURCE_DIR}/include)
set (PROJECT_LIB_DIR ${CMAKE_CURRENT_SOURCE_DIR}/lib)
set(LIBRARIES
libemsg.a
libzmq.a
libprotobuf.a
libprotobuf-c.a
libpthread.a
libstdc++.a
)
#For controller : Client
SET(EXECUTABLE test_controller)
project (${EXECUTABLE})
include_directories(
${PROJECT_INCLUDE_DIR}
${EMSG_INCLUDE_DIR}
$ENV{TARGETROOT}/usr/include
)
link_directories(
${PROJECT_LIB_DIR}
${EMSG_LIB_DIR}
$ENV{TARGETROOT}/usr/lib
)
set(SRCS
test_controller.cpp
)
add_executable( ${EXECUTABLE} ${SRCS})
target_link_libraries( ${EXECUTABLE} ${LIBRARIES} )
Then it makes the error like below.
[ 40%] Built target emsg
Linking CXX executable ../../../bin/test_controller
/usr/mipsel-buildroot-linux-gnu/sysroot/usr/lib/libstdc++.so: error adding symbols: File in wrong format
collect2: error: ld returned 1 exit status
make[2]: *** [../bin/test_controller] Error 1
make[1]: *** [test/emsg_test/CMakeFiles/test_controller.dir/all] Error 2
So I checked the format of libstdc++.so. Then it's ELF 32-bit LSB shared object, MIPS, MIPS32. That's the right version. Then what can I do to solve?
/usr/mipsel-buildroot-linux-gnu/sysroot# file /usr/mipsel-buildroot-linux-gnu/sysroot/usr/lib/libstdc++.*
/usr/mipsel-buildroot-linux-gnu/sysroot/usr/lib/libstdc++.a: current ar archive
/usr/mipsel-buildroot-linux-gnu/sysroot/usr/lib/libstdc++.so: symbolic link to `libstdc++.so.6.0.19'
/usr/mipsel-buildroot-linux-gnu/sysroot/usr/lib/libstdc++.so.6: symbolic link to `libstdc++.so.6.0.19'
/usr/mipsel-buildroot-linux-gnu/sysroot/usr/lib/libstdc++.so.6.0.19: ELF 32-bit LSB shared object, MIPS, MIPS32 rel2 version 1 (SYSV), dynamically linked, with unknown capability 0xf41 = 0x756e6700, not stripped
New information
It seems to be the problem of buildroot. I checked the sysroot value of mips-linux-gnu-gcc.
This is the result before installing buildroot.
$ mips-linux-gnu-gcc --print-sysroot
/home/vagrant/bd1/mips-2014.05/bin/../mips-linux-gnu/libc
This is the result after installing buildroot.
$ mips-linux-gnu-gcc --print-sysroot
/usr/usr/mipsel-buildroot-linux-gnu/sysroot/soft-float/el
I also found the post about similar problem. But it's old issue.
Please use the CMake toolchain file provided by Buildroot. It is generated in $(HOST_DIR)/usr/share/buildroot/toolchainfile.cmake. Use it this way:
cmake -DCMAKE_TOOLCHAIN_FILE=/path/to/host/usr/share/buildroot/toolchainfile.cmake
And then you can remove all your other -DCMAKE_ variable, since the toolchain file indicates to CMake which compiler to use, which flags, etc.
I found the reason. The main reason is sysroot path. Buildroot organizes all toolchain into $BUILDROOT/output/host/. So you should change the PATH environment like below.
HOST_BINARY="$BUILDROOT/output/host/usr/bin"
PATH="${PATH}:${HOST_BINARY}"
Where $BUILDROOT is the folder where buildroot is extracted.
You should use toolchain below $BUILDROOT/output/host/usr/bin.
I have problem with building aplication with opencv library for ARM.
I installed Opencv 2.4.6.1 for my pc with helping this a tutorial http://docs.opencv.org/doc/tutorials/introduction/linux_install/linux_install.html#linux-installation
After that i try build example for my pc:
gcc main.c -o main ´pkg-config --libs --clags opencv´ -lpthread
It works.
Next, i install arm-linux-gnueabihf-gcc, wrote example and tryied it. It works.
now i make opencv library for ARM
cd /opt/opencv-2.4.6.1/platforms/linux
mkdir build_hardfp
pico arm-gnueabi.toolchain.cmake
change 4.6 to 4.7.2
cd build_hardfp
cmake -DCMAKE_TOOLCHAIN_FILE=../arm-gnueabi.toolchain.cmake -DWITH_TBB=OFF -DWITH_QT=OFF -D SOFTFP=OFF -D WITH_V4L=ON -D WITH_OPENGL=ON –D CMAKE_BUILD_TYPE=RELEASE –D BUILD_SHARED_LIBS=OFF -D CMAKE_INSTALL_PREFIX=/opt/opencv-2.4.6.1/rpi ../../..
make
make install
And now my problem:
I try build my example
arm-linux-gnueabihf-gcc -o main main.c -lpthread -I/opt/opencv-2.4.6.1/rpi/include -I/opt/opencv-2.4.6.1/rpi/include/opencv -I/opt/opencv-2.4.6.1/rpi/lib -L/opt/opencv-2.4.6.1/rpi/ -lcv -lhighgui
main.c: In function ‘main’:
main.c:12:8: warning: assignment makes pointer from integer without a cast [enabled by default]
/home/honza/rpi/tools/arm-bcm2708/gcc-linaro-arm-linux-gnueabihf-raspbian/bin/../lib/gcc/arm-linux-gnueabihf/4.7.2/../../../../arm-linux-gnueabihf/bin/ld: cannot find -lcv
/home/honza/rpi/tools/arm-bcm2708/gcc-linaro-arm-linux-gnueabihf-raspbian/bin/../lib/gcc/arm-linux-gnueabihf/4.7.2/../../../../arm-linux-gnueabihf/bin/ld: cannot find -lhighgui
collect2: error: ld returned 1 exit status
Probably i must have all the dependencies compile for ARM architecture. I think, i took care of this in previous steps, with using cmake.
Maybe i didn't set paths.
What am I doing wrong and how to fix it?
You use old names for OpenCV libraries : -lcv -lhighgui. OpenCV has new structure from 2.0 version. Use this flags : -lopencv_core -lopencv_highgui.
I'm trying to cross-compile Qt5 for the Freescale i.MX6 processor. I've already built an image using the latest Yocto package.
Before compilation of qtbase, a test for OpenGL functionality is first ran by compiling an some OpenGL code. However, during this test the compiler complains that an incompatible libc.so.6 is found.
I've discovered in another post (which I can't find at the moment), that such an error occurs because /lib/libc.so.6 is actually a symbolic link which points to the actual shared object file. However, the compiler does not use the shared object file pointed to by libc.so.6, instead trying to link to the symbolic link itself, thus the compatibility issue.
Here is the output when the configure script is ran:
OpenGL ES 2.x auto-detection... ()
/home/Desktop/poky-dylan-9.0.0/build/tmp/sysroots/x86_64-linux/usr/bin/armv7a-vfp-neon-poky-linux-gnueabi/arm-poky-linux-gnueabi-g++ -c -pipe -mfloat-abi=softfp -O2 -O2 -march=armv7-a -mfpu=neon -DLINUX=1 -DEGL_API_FB=1 -Wall -W -fPIE -I../../../mkspecs/devices/linux-imx6-g++ -I. -I/home/Desktop/poky-dylan-9.0.0/build/tmp/deploy/images/mountpoint/usr/include -o opengles2.o opengles2.cpp
/home/Desktop/poky-dylan-9.0.0/build/tmp/sysroots/x86_64-linux/usr/bin/armv7a-vfp-neon-poky-linux-gnueabi/arm-poky-linux-gnueabi-g++ -Wl,-rpath-link,/home/Desktop/poky-dylan-9.0.0/build/tmp/deploy/images/mountpoint/usr/lib -Wl,-O1 -o opengles2 opengles2.o -L/home/Desktop/poky-dylan-9.0.0/build/tmp/deploy/images/mountpoint/usr/lib -lGLESv2 -lEGL -lGAL
/home/Desktop/poky-dylan-9.0.0/build/tmp/sysroots/x86_64-linux/usr/libexec/armv7a-vfp-neon-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/4.7.2/ld: skipping incompatible /lib/libc.so.6 when searching for /lib/libc.so.6
/home/Desktop/poky-dylan-9.0.0/build/tmp/sysroots/x86_64-linux/usr/libexec/armv7a-vfp-neon-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/4.7.2/ld: cannot find /lib/libc.so.6
/home/Desktop/poky-dylan-9.0.0/build/tmp/sysroots/x86_64-linux/usr/libexec/armv7a-vfp-neon-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/4.7.2/ld: skipping incompatible /usr/lib/libc_nonshared.a when searching for /usr/lib/libc_nonshared.a
/home/Desktop/poky-dylan-9.0.0/build/tmp/sysroots/x86_64-linux/usr/libexec/armv7a-vfp-neon-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/4.7.2/ld: cannot find /usr/lib/libc_nonshared.a
/home/Desktop/poky-dylan-9.0.0/build/tmp/sysroots/x86_64-linux/usr/libexec/armv7a-vfp-neon-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/4.7.2/ld: cannot find /lib/ld-linux.so.3
collect2: error: ld returned 1 exit status
gmake: *** [opengles2] Error 1
OpenGL ES 2.x disabled.
The OpenGL ES 2.0 functionality test failed!
Here is the script I used to supply the proper options to the configure script:
#!/bin/sh
./configure -v -opensource -confirm-license -no-pch -opengl es2 \
-make libs -device imx6 \
-make examples -make demos \
-device-option CROSS_COMPILE=/home/Desktop/poky-dylan-9.0.0/build/tmp/sysroots/x86_64-linux/usr/bin/armv7a-vfp-neon-poky-linux-gnueabi/arm-poky-linux-gnueabi- \
-sysroot /home/Desktop/poky-dylan-9.0.0/build/tmp/deploy/images/mountpoint -no-gcc-sysroot \
-prefix /opt/qt5
At the moment, I'm considering just renaming the actual shared object file to libc.so.6, but that doesn't seem like a good way to fix things.
It seems that you are compiling against the wrong libc. The location of the correct libc should be: /home/Desktop/poky-dylan-9.0.0/build/tmp/deploy/images/mountpoint/lib/ Can you check that? Run in that folder:
file libc.so.6
Have a look if the architecture is fine. I do not have the sources in front of me, so please give feedback if things are going wrong.
Your application is compiled in a chroot environment (see man chroot). The folder /home/Desktop/poky-dylan-9.0.0/build/tmp/deploy/images/mountpoint acts as the new rootfolder for your application. This is configured in the -sysroot option of your configure script. This is not valid for gcc, because the -no-gcc-sysroot is on. So the linker is looking to your native /lib/ folder to find the libraries. They are not there of course.
So, can you try the following things:
1) remove the -no-gcc-sysroot option in the configure script. Configure again and try to make.
2) This can possibly fail because the compiler does not find back it's own components. Please mount the directory of the compiler into your chroot enviroment. Run the next commands:
mkdir /home/Desktop/poky-dylan-9.0.0/build/tmp/deploy/images/mountpoint/usr/bin -p
mount --bind /home/Desktop/poky-dylan-9.0.0/build/tmp/sysroots/x86_64-linux/usr/bin/ /home/Desktop/poky-dylan-9.0.0/build/tmp/deploy/images/mountpoint/usr/bin
Configure again and try again to make.
3) If it still is not working, the cross-compiler is not set properly. Change into the configure script argument list the CROSS_COMPILE argument:
CROSS_COMPILE=/usr/bin/armv7a-vfp-neon-poky-linux-gnueabi/arm-poky-linux-gnueabi-
I wish you good luck. Let me know if it is working or not.
I am able to make a shared library without problems. I create libcbitcoin.so (without any errors) and attempt to link against it with an executable as well as OpenSSL libraries. I use this command:
gcc -L/media/sf_BitEagle_Projects/cbitcoin/build/bin -lcbitcoin \
-Wl-rpath,/media/sf_BitEagle_Projects/cbitcoin/build/bin -lssl -lcrypto \
-L/usr/local/ssl/lib/ -o /media/sf_BitEagle_Projects/cbitcoin/build/bin/testCBAddress \
/media/sf_BitEagle_Projects/cbitcoin/build/obj/testCBAddress.o \
/media/sf_BitEagle_Projects/cbitcoin/build/obj/CBOpenSSLCrypto.o
The bin directory is the location of the library. The obj directory has the object files I wish to link into an executable. In the command I use the -L, -l and -rpath* options which I thought was all that is needed for linking in Linux. It seems I am wrong since I get errors like:
/media/sf_BitEagle_Projects/cbitcoin/test/testCBAddress.c:40:
undefined reference to `CBNewByteArrayFromString'
CBNewByteArrayFromString is found in the library. For some reason it is not being linked. OpenSSL too:
/media/sf_BitEagle_Projects/cbitcoin/dependencies/crypto/CBOpenSSLCrypto.c:37:
undefined reference to `SHA1'
How do I get the linking to work?
GCC version: gcc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3
It is on Linux Mint 13 (Maya).
Put the libraries after the object files on the link command line:
gcc /media/sf_BitEagle_Projects/cbitcoin/build/obj/testCBAddress.o \
/media/sf_BitEagle_Projects/cbitcoin/build/obj/CBOpenSSLCrypto.o \
-L/media/sf_BitEagle_Projects/cbitcoin/build/bin \
-lcbitcoin -Wl-rpath,/media/sf_BitEagle_Projects/cbitcoin/build/bin \
-L/usr/local/ssl/lib/ -lssl -lcrypto \
-o /media/sf_BitEagle_Projects/cbitcoin/build/bin/testCBAddress
If you don't do that, the linker may decide that it needs nothing from a particular library at the stage of the link where it scans the library, and then it won't rescan the library later after it finds some undefined symbols in the object files. If you put the object files first, you don't run into this problem.
I think it is caused by can not find symbol. GCC will first go through from the left and will try to put the library file at the end.