/usr/bin/ld: i386:x86-64 architecture of input file `build/gengenrtl.o' is incompatible with i386 output
/usr/bin/ld: i386:x86-64 architecture of input file `build/errors.o' is incompatible with i386 output
/usr/bin/ld: build/gengenrtl.o: file class ELFCLASS64 incompatible with ELFCLASS32
/usr/bin/ld: final link failed: File in wrong format
collect2: error: ld returned 1 exit status
I don't get if the problem is ld or the given library.
my configuration is
CC="gcc -m32" \
CFLAGS="-m32" \
LD="<path>/bin/32/binutils/2.23.2/bin/ld" \
LDFLAGS="-m32" \
./configure \
--build=i586-pc-linux-gnu \
--host=i586-pc-linux-gnu \
--target=i586-pc-linux-gnu \
--enable-shared \
--enable-static \
--enable-languages=c,c++ \
--enable-bootstrap \
--prefix=<path>/bin/32/gcc/i586 \
--disable-stage1-checking \
--with-gmp=<path>/lib/32/gmp/5.1.2 \
--with-mpfr=<path>/lib/32/mpfr/3.1.2 \
--with-mpc=<path>/lib/32/mpc/1.0.1 \
--with-cloog=<path>/lib/32/cloog/0.18.0 \
--without-ppl
Apparently I can't change the ld executable so easily, gcc keeps compiling with the global system /usr/bin/ld.
Someone can say what is going on here and how to fix this linking phase ?
I'm under Ubuntu 64 bit and I'm trying to compile a 32 bit build of gcc, of course I have already compiler gmp, mpc, mpfr for 32 bits.
Of course you can build gcc from source as 32-bit, using a 64-bit OS, compiler and linker. The problem is definitely not "ld".
You're doing exactly the right thing: specifying "-m32" in CFLAGS and LDFLAGS.
The problem is that build/gengenrtl.o and build/errors.o appear to have been built for 64-bit (instead of 32-bit).
SUGGESTIONS:
1) Check the makefile, and check your build log. See if there's anything "different" about the build commands for those two files.
2) Use the "nm" command to verify that the rest of your *.o object files were correctly built as 32-bit - that only "gengenrtl.o" and "errors.o" were (incorrectly) built as ELFCLASS64.
'Hope that helps...
I have solved similar problem (Compile gcc on amd64, for running on i686, and target is mips) with adding following to make command line:
CC="gcc -m32" CXX="g++ -m32" LDFLAGS=-m32
No need to specify full path to ld. But you forgot specify which C++ compiler to use.
Related
I have a c++ program using opencv libraries. I am able successfully to build my program on MAC OS using dynamic opencv libraries using the following command:
g++ -std=c++11 -Iinclude/ -o detect2 detect2.cpp -Llib3/ \
-lopencv_objdetect \
-lopencv_imgproc \
-lopencv_core \
-lopencv_videoio \
-lopencv_highgui
The above command generates the detect2 executable which works perfectly fine.
However, I want to statically link the opencv libraries so that later I can integrate this program into our MAC app so that we can distribute easliy without asking the user to install opencv on their MAC.
Following is the command I am using to build detect2.cpp using static opencv libs
g++ -std=c++11 -Iinclude/ -o detect2 detect2.cpp \
lib2/libopencv_objdetect.a \
lib2/libopencv_imgproc.a \
lib2/libopencv_core.a \
lib2/libopencv_videoio.a \
lib2/libopencv_highgui.a
But I get the following error:
ld: symbol(s) not found for architecture x86_64 clang: error: linker
command failed with exit code 1 (use -v to see invocation)
If I use -static in the g++ command then I get
ld: library not found for -lcrt0.o
clang: error: linker command failed with exit code 1 (use -v to see invocation)
Please let me know how can I build my cpp program with static opencv libs on MACOS. Thanks
I was building gnu C/C++ compiler tools under windows 7 using Cygwin environment.
I am getting following errors while building the glibc . I have tried glibc 2.23 through glibc 2.30 sources.
During building all of them linker shows the same error : undefined reference to `_DYNAMIC'
I am trying to build a cross tool that will run under windows that will generate linux elf executables to run on the linux OS.
I was wondering if someone can help
I used bin utils 2.30 and 2.32
Linux headers 3.xx through 5.xx
Gcc 4.9.1 through 9.1.0
Glibc 2.23 through 2.30
target =i686-elf
DUMP from the screen
mv -f /home/RahmanA/src/gcc_port_4.9.1/build-glibc/elf/rtld-libc.aT /home/RahmanA/src/gcc_port_4.9.1/build-glibc/elf/rtld-libc.a
make[3]: Leaving directory '/home/RahmanA/src/gcc_port_4.9.1/glibc-2.23/elf'
i686-elf-gcc -nostdlib -nostartfiles -r -o /home/RahmanA/src/gcc_port_4.9.1/build-glibc/elf/librtld.os '-Wl,-(' /home/RahmanA/src/gcc_port_4.9.1/build-glibc/elf/dl-allobjs.os /home/RahmanA/src/gcc_port_4.9.1/build-glibc/elf/rtld-libc.a -lgcc '-Wl,-)' \
-Wl,-Map,/home/RahmanA/src/gcc_port_4.9.1/build-glibc/elf/librtld.os.map
i686-elf-gcc -nostdlib -nostartfiles -shared -o /home/RahmanA/src/gcc_port_4.9.1/build-glibc/elf/ld.so.new \
-Wl,-z,relro -Wl,--hash-style=both -Wl,-z,defs \
/home/RahmanA/src/gcc_port_4.9.1/build-glibc/elf/librtld.os -Wl,--version-script=/home/RahmanA/src/gcc_port_4.9.1/build-glibc/ld.map \
-Wl,-soname=ld-linux.so.2 \
-Wl,-defsym=_begin=0
/home/RahmanA/src/gcc_port_4.9.1/build-glibc/elf/librtld.os: In function `elf_machine_load_address':
**/home/RahmanA/src/gcc_port_4.9.1/glibc-2.23/elf/../sysdeps/i386/dl-machine.h:58: undefined reference to `_DYNAMIC'
/home/RahmanA/src/gcc_port_4.9.1/build-glibc/elf/librtld.os: In function `elf_get_dynamic_info':
/home/RahmanA/src/gcc_port_4.9.1/glibc-2.23/elf/get-dynamic-info.h:45: undefined reference to `_DYNAMIC'**
When I try to compile GCC 4.8.0 as a part of a greater system, in a custom directory. I have no sudo rights on this server and therefore I'm building everything from source. However, I can't get the dependencies gmp, mpfr and mpc to work. When running configure it gives me:
configure: error: Building GCC requires GMP 4.2+, MPFR 2.4.0+ and MPC 0.8.0+.
Try the --with-gmp, --with-mpfr and/or --with-mpc options to specify their locations.
config.log gives me:
configure:5619: checking for the correct version of the gmp/mpfr/mpc libraries
configure:5650: gcc -o conftest -g -O2 -Wno-error=unused-value -I$SRC/gmp/ -I$SRC/mpc/src/.libs -lmpc -lmpfr -lgmp >&5
/usr/bin/ld: cannot find -lmpc
collect2: ld returned 1 exit status
So I tried to get mpfr, gmp and mpc and build it manually from source, as I have no rights to install on the system itself. I ran ./contrib/download_prerequisites to get the libraries. I ran configure again, it gave me the same error. So I also compiled them and in my gcc dir I did:
cd mpfr; ./configure; make
cd ../gmp; ./configure; make
cd ../mpc; ./configure --with-mpfr-include=$SRC/mpfr --with-mpfr-lib=$SRC/mpfr/.libs/ --with-gmp=$SRC/gmp; make; cd ..
Note that just using --with-mpfr did not work for some reason.
cd $SRC/build
../configure \
--build=x86_64-linux-gnu \
CC=gcc \
CFLAGS='-g -O2 -Wno-error=unused-value' \
--disable-bootstrap --enable-checking=none \
--disable-multi-arch --disable-multilib \
--enable-languages=c,c++ \
--with-gmp-lib=$SRC/gmp/.libs \
--with-gmp-include=$SRC/gmp/ \
--with-mpc-include=$SRC/mpc/src \
--with-mpc=$SRC/mpc \
--with-mpfr-lib=$SRC/mpfr/.libs \
--with-mpfr-include=$SRC/mpfr \
--prefix=$SRC/prefix
where $SRC is my gcc directory. However, at the last command it gave me this error in the build/config.log:
gcc -o conftest -g -O2 -Wno-error=unused-value -I$SRC/gmp/ -I$SRC/mpfr -I$SRC/mpc/src conftest.c -L$SRC/gmp/.libs -L$SRC/mpfr/.libs -L$SRC/mpc/lib -lmpc -lmpfr -lgmp >&5
/usr/bin/ld: cannot find -lmpc
collect2: ld returned 1 exit status
It is obvious that after running make mpc does not have a lib directory, or anything containing shared object files. So I do not know how I have to link gcc with the mpc library.
Does anyone know what I should do?
I'm trying to get llvm-gcc 4.2.2.9 to compile on this x86_64 system which runs the 3.0.0-21-generic kernel. llvm 2.9 itself builds fine. I suspected the downloadable version of llvm-gcc was causing some other problems, so I decided to build llvm-gcc myself.
Like suggested in the README.LLVM I configured with
../llvm-gcc-4.2-2.9.source/configure \
--prefix=/opt/llvm-gcc4.2-2.9/../llvm-gcc4.2-2.9-install \
--disable-multilib \
--program-prefix=llvm- \
--enable-llvm=/opt/llvm-2.9 \
--host=x86_64-generic-linux-gnu
--enable-languages=c,c++
I'm running this from the /opt/llvm-gcc4.2-2.9 directory, while the sources are sitting in /opt/llvm-gcc-4.2-2.9.source and my llvm 2.9 lives in /opt/llvm-2.9. Note that I'm setting the --host instead of the --target as this implicitly sets the --target to the same architecture.
make does build a lot of stuff (producing a sizeable amount of warnings) when finally stopping at this error:
make[3]: Entering directory `/opt/llvm-gcc4.2-2.9/gcc'
/opt/llvm-gcc4.2-2.9/./gcc/xgcc -B/opt/llvm-gcc4.2-2.9/./gcc/ -B/opt/llvm-gcc4.2-2.9/../llvm-gcc4.2-2.9-install/x86_64-generic-linux-gnu/bin/ -B/opt/llvm-gcc4.2-2.9/../llvm-gcc4.2-2.9-install/x86_64-generic-linux-gnu/lib/ -isystem /opt/llvm-gcc4.2-2.9/../llvm-gcc4.2-2.9-install/x86_64-generic-linux-gnu/include -isystem /opt/llvm-gcc4.2-2.9/../llvm-gcc4.2-2.9-install/x86_64-generic-linux-gnu/sys-include -O2 -O2 -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -I. -I. -I../../llvm-gcc-4.2-2.9.source/gcc -I../../llvm-gcc-4.2-2.9.source/gcc/. -I../../llvm-gcc-4.2-2.9.source/gcc/../include -I../../llvm-gcc-4.2-2.9.source/gcc/../libcpp/include -I../../llvm-gcc-4.2-2.9.source/gcc/../libdecnumber -I../libdecnumber -I/opt/llvm-2.9/include -g0 -finhibit-size-directive -fno-inline-functions -fno-exceptions -fno-zero-initialized-in-bss -fno-toplevel-reorder -fno-omit-frame-pointer -fno-asynchronous-unwind-tables \
-c ../../llvm-gcc-4.2-2.9.source/gcc/crtstuff.c -DCRT_BEGIN \
-o crtbegin.o
In file included from /usr/include/stdio.h:28,
from ../../llvm-gcc-4.2-2.9.source/gcc/tsystem.h:90,
from ../../llvm-gcc-4.2-2.9.source/gcc/crtstuff.c:68:
/usr/include/features.h:323:26: error: bits/predefs.h: No such file or directory
/usr/include/features.h:356:25: error: sys/cdefs.h: No such file or directory
/usr/include/features.h:388:23: error: gnu/stubs.h: No such file or directory
I find it a bit odd that the include path goes from my system's stdio.h back to llvm-gcc headers and then tries again to include system headers. But maybe that's normal?
After that error hundreds of lines with more errors follow from the same compilation unit.
Could it be that my system's gcc 4.6.1 or my system's headers maybe grew incompatible with the dated llvm-gcc 4.2 headers? Then again, I know that on a different system (running the 2.6 kernel) gcc 4.5.2 plays well with llvm 2.7's gcc 4.2.
I'm at a loss here, because I do need a recent llvm 2.*, and the other two acceptable llvm versions (2.7, 2.8) didn't show any result more helpful.
It seems that /usr/include on your system provides 32-bit headers, thus the compilation fails since you do not have all multilib headers installed. You might need to patch llvm-gcc the same way as your distribution patches gcc in order to find the headers locations.
Alternatively, you might try to install 32-bit headers and try multilib build of llvm-gcc.
But the best way will be switch to LLVM 3.1 and clang :)
I tried to compile LLVM 2.4 on Mac OS X Lion with this command.
./configure --enable-pic --prefix=/usr/local CC="gcc -arch i386" CXX="g++ -arch i386"
I got this error.
Undefined symbols for architecture i386:
"llvm::PATypeHolder::get() const", referenced from:
llvm::ELFWriter::EmitGlobal(llvm::GlobalVariable*) in libLLVMCodeGen.a(ELFWriter.o)
ld: symbol(s) not found for architecture i386
collect2: ld returned 1 exit status
What's wrong with this?
For cross compiling configure likes it when you supply the host, target and build using the machine tuple.
If you're unfamiliar with what your machine tuple is, you can find it using
gcc -dumpmachine
Which, using Lion reports:
i686-apple-darwin11
Note that on Lion x86_64-apple-darwin11 is valid for 64bit.. But, to use that when building llvm:
./configure \
--enable-pic \
--prefix=/usr/local \
--host=i686-apple-darwin11 \
--target=i686-apple-darwin11 \
--build=i686-apple-darwin11
That should do it, but you might want to include
--enable-languages=c,c++,obj-c
--enable-optimized
You can also verify the libraries you're linking against using 'file' and 'otool'. Or, if it's a static archive that you're linking against (which looks to be the case..) my quickie test is
ar p somelib.a $(ar t somelib.a | grep \.o | tail -1) | file -
You're not going to run into an i386 OSX Lion box, so building clang for i386 seems unnecessary - you could probably build the 64 bit version (whatever it chooses by default), and then when you compile WITH that, you would specify '-m32' or '-m64' in your CFLAGS or CXXFLAGS to generate the correct bit depth of objects.
-n