This is the mail archive of the gcc-help@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Cross compiled gcc 4.9.3 fails with 'unrecognised emulation mode: -dynamic-linker'


5.8.2015, 0:56, Fredrik Fornwall kirjoitti:

Let's analyze this a little :

I got a gcc 4.9.3 binary cross compiled with:

Configured with: /home/fornwall/termux/gcc/src/configure
-disable-dependency-tracking --prefix=/data/data/com.termux/files/usr
--disable-rpath --disable-rpath-hack --host=i686-linux-android

When using the bare '--host=', the configuration has traditionally "guessed" that
$host = $target, ie if you had used :

--host=i686-linux-android --target=i686-linux-android

The $build system then would be guessed via tests for the $build system.


--enable-languages=c,c++ --with-system-zlib
--disable-multilib --disable-lto --with-gmp=/data/data/com.termux/files/usr
--with-mpfr=/data/data/com.termux/files/usr
--with-mpc=/data/data/com.termux/files/usr

Were gmp, mpfr and mpc earlier compiled for "--host=i686-linux-android" ? They should have been... Quite usual is to let the $host compiler to build them during the
GCC build, not prebuid/preinstall them.


--with-stage1-ldflags=-specs=/home/fornwall/dc/termux.spec
--with-arch=i686 --with-tune=atom--with-fpmath=sse
--disable-nls --enable-shared --disable-static
--libexecdir=/data/data/com.termux/files/usr/libexec

When compiling a C program, gcc test.c, I get:

ld: unrecognised emulation mode: -dynamic-linker
Supported emulations: elf_i386 i386linux elf32_x86_64
collect2: error: ld returned 1 exit status

due to the following collect2 call (as told by gcc -v test.c) missing
an argument to the -mflag:

COMPILER_PATH=. LIBRARY_PATH=.
COLLECT_GCC_OPTIONS='-v' '-mtune=atom' '-march=i686'
/data/data/com.termux/files/usr/libexec/gcc/i686-linux-android/4.9.3/collect2
-m -dynamic-linker
-pie /data/data/com.termux/files/usr/lib/gcc/i686-linux-android/4.9.3/../../../crtbegin_dynamic.o
-L/data/data/com.termux/files/usr/lib/gcc/i686-linux-android/4.9.3
-L/data/data/com.termux/files/usr/lib/gcc/i686-linux-android/4.9.3/../../..
/data/data/com.termux/files/usr/tmp//ccxXWQIJ.o
-lgcc -lc -ldl -lgcc
/data/data/com.termux/files/usr/lib/gcc/i686-linux-android/4.9.3/../../../crtend_android.o

Where is the the problem? Is --host=i686-linux-android an incorrect host?



Ok, your question is whether producing a native GCC for 'i686-linux-android' works (seems to succeed). And whether the resulted native GCC should work (doesn't seem to work)...

Googling with "producing a native GCC for Android x86" didn't give any clues :( People seem
to be more interested on the ARM variation of Android....

So you should to find out why the compiler doesn't give a proper argument for the '-m' flag for the linker. You looking at the '*link:' spec sounds sane. When I looked one target which I
remembered to give those '-m' options for linker, the Hitachi H8/300 :

*link:
%{mh:%{mn:-m h8300hn}} %{mh:%{!mn:-m h8300h}} %{ms:%{mn:-m h8300sn}} %{ms:%{!mn:-m h8300s}}

there they were... But there are other specs which could have those like the '*link_command:'...
In yours there were none :

*link:
+ %{!nopie: %{!static: %{!shared: %{!nostdlib: %{!nostartfiles:
%{!fno-PIE: %{!fno-pie: -pie}}}}}}}




Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]