Re: [PATCH][ARM] Support arm-android-eabi

Top Page

Reply to this message
Author: Doug Kwan (關振德)
Date:  
To: Joseph S. Myers
CC: Mark Mitchell, gcc-patches
Subject: Re: [PATCH][ARM] Support arm-android-eabi
2008/7/9 Joseph S. Myers <joseph@???>:
> This patch has broken the build for arm-*-linux-gnueabi; it's now looking
> for a crt0.o file that's inappropriate for this target.
>
> The patch adds definitions of the macros CC1_SPEC, CC1PLUS_SPEC, LIB_SPEC,
> STARTFILE_SPEC, ENDFILE_SPEC unconditionally to bpabi.h. However, some
> ARM targets rely on the definitions of these macros provided by previous
> headers (or maybe on the macros not being defined when a subsequent header
> is included - I don't know about that possibility), and the replacements
> are inappropriate for those targets. In the case of arm-*-linux-gnueabi,
> at least your definition of STARTFILE_SPEC is wrong.


The patch that got checked in was the second version. In the first
version, I did use a seperate android.h header to override those
macros. Could that a look at the patch in the first mail this thread
to see if that first version does it right?

> You need to fix GCC so that all targets including bpabi.h (that is
> arm*-*-linux-*eabi, arm*-*-uclinux-*eabi, arm*-*-eabi*,
> arm*-*-symbianelf*) have the same definitions of these macros (after the
> full set of target headers is included) they used to, except for the
> intended Android definitions for the generic arm*-*-eabi* only. (It's
> probably harmless for the other targets to handle -mandroid, but also
> unnecessary.) Note that the definitions may depend on how the compiler
> was configured in some cases (the STARTFILE_SPEC definition in
> config/linux.h does). One possibility would be that these new definitions
> go in a separate header only included for the generic arm*-*-eabi* target
> (note that I have not checked that these new definitions are the same as
> the old ones for that target unless you use -mandroid).
>
> --
> Joseph S. Myers
> joseph@???
>