Re: [PATCH 1 of 2] libc/eglibc: [OS X] Don't Use __block as a Name of an Argument

[Philip Belemezov <philip@belemezov.net>]

On 13.04.2013 12:56, Yann E. MORIN wrote:
> Philip, All,
>
> On Sat, Apr 13, 2013 at 07:48:08AM +0300, Philip Belemezov wrote:
>> On 13.04.2013 00:51, Yann E. MORIN wrote:
>>> On Tue, Mar 26, 2013 at 05:25:31PM +0200, Philip Belemezov wrote:
>>>> # HG changeset patch
>>>> # User Philip Belemezov <philip@belemezov.net>
>>>> # Date 1364300812 -7200
>>>> # Node ID fcdf7fc7fd1c00715c3d9651ff00d805ecfb8aa8
>>>> # Parent  0fc56e62cecf07e4cdaf866ee24d6893c4ade436
>>>> libc/eglibc: [OS X] Don't Use __block as a Name of an Argument
>>>>
>>>> Apple's GCC defines __block as
>>>>
>>>> #define __block __attribute__((__blocks__(byref)))
>>>>
>>>> which causes compilation to fail (attribute cannot be applied to argument).
>>>
>>> I do not understand why this patch is needed at all: we're not building
>>> (e)glibc with the Apple-patched native gcc, but with a plain gcc that we
>>> just build ourselves in the process.
>>>
>>> Unless I missed something... Can you elaborate, please?
>>
>> I don't have the details any more, but I believe this was happening during
>> the bootstrap phase, before the target gcc has been built.
>
> The only case where we may do something in (e)glibc without having a
> target gcc is to install the libc headers when using LinuxThreads, which
> have not be supported in (e)glibc for some time (some years, now).
>
> In all other cases, building anything libc involves having a target gcc
> first.
>
> The only reason we'd use the native compiler (and hence your
> Apple-severed version of gcc) would be if (e)glibc needed to build a
> program that runs on your build machine, and I am not aware of such a
> case ( but I am sometimes easily proven wrong! ;-) )
>
>> Let me reproduce the failure and see where exactly it choke.
>
> Thank you for investigating! :-)
>
> Regards,
> Yann E. MORIN.
>


Hi, Yann!

I am not able to reproduce this anymore.  I don't recall doing any major 
changes on my system such as compiler updates.  Perhaps it occurred with 
a different set of packages/versions.

I've done two successful clean builds without the need for that patch.
So, please drop it.


-- Phil


--
For unsubscribe information see http://sourceware.org/lists.html#faq