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

login
register
mail settings
Submitter Philip Belemezov
Date March 26, 2013, 3:25 p.m.
Message ID <fcdf7fc7fd1c00715c3d.1364311531@Loki.local>
Download mbox | patch
Permalink /patch/231418/
State Rejected
Headers show

Comments

Philip Belemezov - March 26, 2013, 3:25 p.m.
# 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).


Signed-Off-By: Philip Belemezov <philip@belemezov.net>


--
For unsubscribe information see http://sourceware.org/lists.html#faq
Yann E. MORIN - April 12, 2013, 9:51 p.m.
Philip, All,

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?

Regards,
Yann E. MORIN.
Philip Belemezov - April 13, 2013, 4:48 a.m.
On 13.04.2013 00:51, Yann E. MORIN wrote:
> Philip, All,
>
> 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?
>
> Regards,
> Yann E. MORIN.
>

Hi, Yann!


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.

Let me reproduce the failure and see where exactly it choke.


Phil

--
For unsubscribe information see http://sourceware.org/lists.html#faq
Yann E. MORIN - April 13, 2013, 9:56 a.m.
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.
Philip Belemezov - April 14, 2013, 8:13 a.m.
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

Patch

diff -r 0fc56e62cecf -r fcdf7fc7fd1c patches/eglibc/2_17/fix_param_name_obstack_free.patch
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/patches/eglibc/2_17/fix_param_name_obstack_free.patch	Tue Mar 26 14:26:52 2013 +0200
@@ -0,0 +1,16 @@ 
+Don't use __block, because Apple's GCC already defines it as
+
+#define __block __attribute__((__blocks__(byref)))
+
+diff -Naur eglibc-2_17-orig/malloc/obstack.h eglibc-2_17-new/malloc/obstack.h
+--- eglibc-2_17-orig/malloc/obstack.h	2012-02-18 04:24:59.000000000 +0200
++++ eglibc-2_17-new/malloc/obstack.h	2013-03-26 12:36:50.000000000 +0200
+@@ -186,7 +186,7 @@
+ 			     void (*) (void *, void *), void *);
+ extern int _obstack_memory_used (struct obstack *);
+ 
+-void obstack_free (struct obstack *__obstack, void *__block);
++void obstack_free (struct obstack *__obstack, void *block);
+ 
+ 
+ /* Error handler called when `obstack_chunk_alloc' failed to allocate