This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Android native build of GCC
- From: Cyd Haselton <chaselton at gmail dot com>
- To: Andrew Haley <aph at redhat dot com>,Hans-Peter Nilsson <hp at bitrange dot com>
- Cc: "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Date: Fri, 06 Feb 2015 05:05:54 -0600
- Subject: Re: Android native build of GCC
- Authentication-results: sourceware.org; auth=none
- References: <54AE581C dot 5070003 at redhat dot com> <alpine dot BSF dot 2 dot 02 dot 1502060258210 dot 10842 at arjuna dot pair dot com> <54D48673 dot 9070901 at redhat dot com> <alpine dot BSF dot 2 dot 02 dot 1502060458370 dot 29537 at arjuna dot pair dot com> <54D49731 dot 7030407 at redhat dot com>
On February 6, 2015 4:28:01 AM CST, Andrew Haley <aph@redhat.com> wrote:
>On 02/06/2015 10:18 AM, Hans-Peter Nilsson wrote:
>> On Fri, 6 Feb 2015, Andrew Haley wrote:
>>> On 06/02/15 08:00, Hans-Peter Nilsson wrote:
>>>> On Thu, 8 Jan 2015, Andrew Haley wrote:
>>>>> Android native GCC can't support LTO because of a lack of support
>for
>>>>> dlopen() in the C library. How should we patch the configury to
>disable
>>>>> LTO by default?
>>>>
>>>> Doesn't setting unsupported_languages in toplevel configure.ac
>>>> work for you?
>>>
>>> I'm sorry, I don't understand this comment.
>>
>> Not sure what's not understood. IIUC you want to disable LTO
>> when building gcc natively on Android? As LTO is considered a
>> "language",
>
>???
>
>LTO is considered a "language"? Who knew?
>
>> disabling it by means of the support for targets or
>> hosts to disable languages (by setting the shell variable
>> unsupported_languages) seemed to make sense...though looking
>> closer, I see the language configury is slightly fudged and
>> needs some code moving to fix that, as e.g. lto-plugin
>> conditionals and special lto handling have snuck in before the
>> unsupported_languages processing. Bah. Never mind.
>
>:-)
>
>Anyway, it turns out that only the LTO plugin should be disabled, and
>it turned out that was due to a bug in the weird shim library being
>used
>to do native Android builds. So I guess we're OK.
>
>Andrew.
Technically not a bug, but a limitation of either fakechroot ported to Android, Android's severely stripped libc, or a combination of the two.
At any rate, the Android GCC 4.9.2 "build" has been used to compile a number of other programs on device...so yeah, we're ok.
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.