I am looking to create a native build of GCC for an ARM system and I am running into some trouble. The build machine is i686-linux. Every tutorial I see tells me how to set up the actual cross compiling suite (which I have already done using crosstools-ng). However, I don't see anything related to compiling native ARM GCC. The configure string I used is below, I have set up the sysroot only with headers. I have also cross-compiled and installed GMP and MPFR.
../../gcc-4.3.5/configure \
--host=arm-unknown-linux-gnueabi \
--build=i686-build_pc-linux-gnu \
--target=arm-unknown-linux-gnueabi \
--prefix=/home/vm/gcc-native/sysroot \
--with-sysroot=/home/vm/gcc-native/sysroot \
--enable-shared --enable-threads --disable-libmudflap --disable-libssp \
--disable-libgomp --disable-libstdcxx-pch --with-gnu-as --with-gnu-ld \
--enable-languages=c,c++ --enable-symvers=gnu --enable-__cxa_atexit \
--disable-nls --disable-multilib \
--with-gmp=/home/vm/gcc-native/sysroot/ \
--with-mpfr=/home/vm/gcc-native/sysroot/
GCC will build for a while but then dies with this:
checking for suffix of object files... configure: error: cannot compute suffix of object files: cannot compile.
I am not sure how this would even run on my system as I am building on i686-linux and the target/host are both arm-linux. My thought right now is to find a ltib distro and looking at a spec file for GCC and trying to follow all of the steps. The GCC that ltib shipped with for my board fails to compile on my system due to conflicts with the std namespace.
Any info/links would be appreciated!
Look in the config.log file (maybe not the top-level one) and see what it was trying to do when the test failed. Just grep for the cannot compute suffix message and you should find the right bit (it won't be at the end of the file).
Note that you'll need a working arm-unknown-linux-gnueabi-gcc on your path somewhere if you want to build a cross-native toolchain. I.e. you need a cross compiler to build cross-native compiler.
Related
Im trying to compile gcc 4.8.5 under Red Hat 6. This is my procedure:
tar -xvzf archive.tar.gz
cd gcc-4.8.5
./configure --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release \
--with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object \
--enable-languages=fortran,c --prefix=/opt/gcc4.8.5
make
Then I get the following error:
make all-am
make[4]: Entering directory `/app/gfortran_build/gcc-4.8.5/host-x86_64-unknown-linux-gnu/lto-plugin'
/bin/sh ./libtool --tag=CC --tag=disable-static --mode=link gcc -Wall -g -module -bindir /opt/gcc4.8.5/libexec/gcc/x86_64-unknown-linux-gnu/4.8.5 -o
liblto_plugin.la -rpath /opt/gcc4.8.5/libexec/gcc/x86_64-unknown-linux-gnu/4.8.5 lto-plugin.lo -Wc,../libiberty/pic/libiberty.a
libtool: link: gcc -shared .libs/lto-plugin.o ../libiberty/pic/libiberty.a -Wl,-soname -Wl,liblto_plugin.so.0 -o .libs/liblto_plugin.so.0.0.0
/usr/bin/ld: ../libiberty/pic/libiberty.a(simple-object-coff.o): relocation R_X86_64_PC32 against undefined symbol `simple_object_set_big_16' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: final link failed: Bad value
collect2: ld returned 1 exit status
I already read about CFLAGS, but I wont get it to work.
kind regards
GCC is documented to need to be built outside of its source tree; see the configuring chapter of its installation documentation:
First, we highly recommend that GCC be built into a separate directory from the sources which does not reside within the source tree. This is how we generally build GCC; building where srcdir == objdir should still work, but doesn’t get extensive testing; building where objdir is a subdirectory of srcdir is unsupported.
So you need to build it according to that rule. Hence your GCC build:
cd gcc-4.8.5
#wrong code from the original question! Don't use that
./configure --enable-bootstrap --enable-shared \
--enable-threads=posix --enable-checking=release \
--with-system-zlib --enable-__cxa_atexit \
--disable-libunwind-exceptions --enable-gnu-unique-object \
--enable-languages=fortran,c --prefix=/opt/gcc4.8.5
is wrong; I would recommend at least:
cd gcc-4.8.5
mkdir ../_BuildGCC
cd ../_BuildGCC
../gcc-4.8.5/configure --enable-bootstrap --enable-shared \
--enable-threads=posix --enable-checking=release \
--with-system-zlib --enable-__cxa_atexit \
--disable-libunwind-exceptions --enable-gnu-unique-object \
--enable-languages=fortran,c --prefix=/opt/gnu \
--program-suffix=-mine
then, after the entire build, probably with
make -j4
followed by some mkdir /opt/gnu with appropriate user and permission, then (in the same _BuildGCC)
make install DESTDIR=/tmp/gccinst
and finally cp -vr /tmp/gccinst/opt/gnu /opt/gnu to be run appropriately (perhaps as root...., and perhaps cp -va)
Then you would add /opt/gnu/bin/ to your PATH variable, and you would use gcc-mine to compile your code.
BTW, GCC is compatible for C programs since the ABI don't change. And GCC 4.8 is obsolete and unsupported. You'll better compile from source the supported versions (listed on gcc.gnu.org; in January 2018, GCC 7.2 & GCC 6.4)
Perhaps your particular Redhat system requires additional/specific CFLAGS to be appended into your configure command. You could ask your Redhat support, or try to append CFLAGS=-fPIE or CFLAGS=-fPIC at the end of your ../gcc-4.8.5/configure command.
At last, you might perhaps get such help on gcc-help#gcc.gnu.org, but you'll better try with a recent GCC. Few GCC folks remember 4.8 ....
If you really need precisely GCC 4.8 (but I doubt that), you could buy costly support (e.g. from RedHat or AdaCore folks) if needed.
With Google I found Installing gcc 4.8 and Linuxbrew on CentOS 6
it worked with the following:
../gcc-4.8.5/configure CC="/opt/gcc4.5/bin/gcc" --prefix=/opt/gcc4.8.5 --enable-languages=c,c++,fortran --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object
The interesting part is CC=...
The installed gcc-version is 4.4. With this version, the compiling fails.
kind regards
I'am trying to run the LibSourcey to use the Webrtc Streaming Server.
The thing is that i can't seem to make it work.
I struggled to cmake the project on my Ubuntu 16.04(Regexp in cmake files) but now its fixed .
The problem that i actually got is a shared object bug at compiling time :
usr/bin/ld: /home/kimmie/ffmpeg_build/lib/libswresample.a(options.o):
relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared object;
recompile with -fPIC
/home/kimmie/ffmpeg_build/lib/libswresample.a: error adding symbols: Bad value
collect2: error: ld returned 1 exit status
av/CMakeFiles/av.dir/build.make:783: recipe for target 'av/libscy_av.so.1.0.2' failed
Any help would be very much appreciated as i don't know what to do now.
I hit this same error on Ubuntu 16.04.
I ended up recompiling FFmpeg with flags to build the shared libraries. Following the code example boxes in the FFmpeg Compilation Guide, I added the following two flags to the ./configure lines where applicable:
--enable-pic
--enable-shared
I removed the --disable-shared flags as well.
I added --enable-pic and --enable-shared to every component and removed the flag if it returned a message that it was unrecognized for that component. At least libx264, libfdk-acc, and libmp3lame needed --enable-shared. And then for the final FFmpeg (copy and pasted from FFmpeg guide linked to above):
PATH="$HOME/bin:$PATH" PKG_CONFIG_PATH="$HOME/ffmpeg_build/lib/pkgconfig" ./configure \
--prefix="$HOME/ffmpeg_build" \
--pkg-config-flags="--static" \
--extra-cflags="-I$HOME/ffmpeg_build/include" \
--extra-ldflags="-L$HOME/ffmpeg_build/lib" \
--bindir="$HOME/bin" \
--enable-gpl \
--enable-libass \
--enable-libfdk-aac \
--enable-libfreetype \
--enable-libmp3lame \
--enable-libopus \
--enable-libtheora \
--enable-libvorbis \
--enable-libvpx \
--enable-libx264 \
--enable-libx265 \
--enable-nonfree \
--enable-pic \
--enable-shared
Note the last two lines in my example are different than the FFmpeg
guide.
After you do all of that, it's probably best to delete the Libsourcey source and build folder and start over with that.
It took me about 4-5 days off and on to finally compile and successfully build Libsourcey with FFmpeg and WebRTC dependencies. I hit some other snags as well, so be sure to tag me if you have other questions. Note: I am noob at Linux building and not solid on all of the concepts; this is just what worked for me and perhaps it will work for you.
You have a linkage error, not a compilation error. You haven't run into a bug,
you have just attempted a linkage that cannot work.
You are trying to build a shared library libscy_av.so. All the object
files that are linked in a shared library must consist of Position Independent
Code. To generate
such an object file with gcc, you compile with the option -fPIC.
The linker discovers that your shared libary requires the object file
options.o, which is a member of the static library libswresample.a. It then
discovers that this options.o is not PIC, and so cannot be linked in
a shared library. The linkage fails and the linker advises you that
options.o must be recompiled with the -fPIC compiler option.
To comply with that advice, you would have to rebuild the static library libswresample.a from source, with -fPIC added to the compiler flags.
You might do that, but it is unusual for object files in a static library to
be PIC, and there is an easier option. Your mistake was in linking against
the static version of libswresample (libswresample.a) rather than the
shared version (libswresample.so), which will be PIC. Just correct that mistake. If you install
libswresample.a from a dev package provided by your package manager, then
it will also provide libswresample.so. If you have built libswresample
from source, then the build system will also build both.
I am working though the Linux from scratch book when I encountered an error configuring Glibc (step 5.7):
checking for sysdeps preconfigure fragments... aarch64 alpha arm configure: error: Old ABI no longer supported
I am using:
../glibc-2.20/configure \
--prefix=/tools \
--host=$LFS_TGT \
--build=$(../glibc-2.20/scripts/config.guess) \
--disable-profile \
--enable-kernel=2.6.32 \
--with-headers=/tools/include \
libc_cv_forced_unwind=yes \
libc_cv_ctors_header=yes \
libc_cv_c_cleanup=yes
I have had no trouble until now. My $LFS_TGT=armv6l-lfs-linux-gnueabihf
you should upgrade to the latest glibc release. most likely you don't have a compiler yet, so when glibc attempts to run a compile test, it fails and assumes you're trying to use an OABI toolchain.
this was fixed here:
https://sourceware.org/git/?p=glibc.git;a=commit;h=34d97d87bb1c08e34d08a9d4be24a3b1d53a4ddb
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.
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.