| Message ID | fcdf7fc7fd1c00715c3d.1364311531@Loki.local |
|---|---|
| State | Rejected |
| Headers | show |
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.
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
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.
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
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
# 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