* [PATCH 0 of 2] [OS X] Fix Compilation of eglibc-2.17 @ 2013-03-26 15:28 Philip Belemezov 2013-03-26 15:28 ` [PATCH 1 of 2] libc/eglibc: [OS X] Don't Use __block as a Name of an Argument Philip Belemezov 2013-03-26 15:28 ` [PATCH 2 of 2] libc/eglibc: [OS X] Don't Redefine Already Defined Types in rpc/types.h Philip Belemezov 0 siblings, 2 replies; 10+ messages in thread From: Philip Belemezov @ 2013-03-26 15:28 UTC (permalink / raw) To: crossgcc Hello! I am sending two patches that enable building eglibc-2.17 (haven't tried earlier versions) on OS X targeting Raspberry PI. The process of getting the toolchain built also involved other steps (installing certain homebrew packages, adjusting paths, etc.). I would like to share these steps, as they may be of help to others. What would be the preferred format for me to share those: the wiki, email? --Phil -- For unsubscribe information see http://sourceware.org/lists.html#faq ^ permalink raw reply [flat|nested] 10+ messages in thread
* [PATCH 1 of 2] libc/eglibc: [OS X] Don't Use __block as a Name of an Argument 2013-03-26 15:28 [PATCH 0 of 2] [OS X] Fix Compilation of eglibc-2.17 Philip Belemezov @ 2013-03-26 15:28 ` Philip Belemezov 2013-04-12 21:51 ` Yann E. MORIN 2013-03-26 15:28 ` [PATCH 2 of 2] libc/eglibc: [OS X] Don't Redefine Already Defined Types in rpc/types.h Philip Belemezov 1 sibling, 1 reply; 10+ messages in thread From: Philip Belemezov @ 2013-03-26 15:28 UTC (permalink / raw) To: crossgcc # 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> 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); + + \f + /* Error handler called when `obstack_chunk_alloc' failed to allocate -- For unsubscribe information see http://sourceware.org/lists.html#faq ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH 1 of 2] libc/eglibc: [OS X] Don't Use __block as a Name of an Argument 2013-03-26 15:28 ` [PATCH 1 of 2] libc/eglibc: [OS X] Don't Use __block as a Name of an Argument Philip Belemezov @ 2013-04-12 21:51 ` Yann E. MORIN 2013-04-13 4:48 ` Philip Belemezov 0 siblings, 1 reply; 10+ messages in thread From: Yann E. MORIN @ 2013-04-12 21:51 UTC (permalink / raw) To: Philip Belemezov; +Cc: crossgcc 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. -- .-----------------.--------------------.------------------.--------------------. | Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: | | +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ | | +33 223 225 172 `------------.-------: X AGAINST | \e/ There is no | | http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. | '------------------------------^-------^------------------^--------------------' -- For unsubscribe information see http://sourceware.org/lists.html#faq ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH 1 of 2] libc/eglibc: [OS X] Don't Use __block as a Name of an Argument 2013-04-12 21:51 ` Yann E. MORIN @ 2013-04-13 4:48 ` Philip Belemezov 2013-04-13 9:56 ` Yann E. MORIN 0 siblings, 1 reply; 10+ messages in thread From: Philip Belemezov @ 2013-04-13 4:48 UTC (permalink / raw) To: Yann E. MORIN; +Cc: crossgcc 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH 1 of 2] libc/eglibc: [OS X] Don't Use __block as a Name of an Argument 2013-04-13 4:48 ` Philip Belemezov @ 2013-04-13 9:56 ` Yann E. MORIN 2013-04-14 8:13 ` Philip Belemezov 0 siblings, 1 reply; 10+ messages in thread From: Yann E. MORIN @ 2013-04-13 9:56 UTC (permalink / raw) To: Philip Belemezov; +Cc: crossgcc 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. -- .-----------------.--------------------.------------------.--------------------. | Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: | | +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ | | +33 223 225 172 `------------.-------: X AGAINST | \e/ There is no | | http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. | '------------------------------^-------^------------------^--------------------' -- For unsubscribe information see http://sourceware.org/lists.html#faq ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH 1 of 2] libc/eglibc: [OS X] Don't Use __block as a Name of an Argument 2013-04-13 9:56 ` Yann E. MORIN @ 2013-04-14 8:13 ` Philip Belemezov 0 siblings, 0 replies; 10+ messages in thread From: Philip Belemezov @ 2013-04-14 8:13 UTC (permalink / raw) To: Yann E. MORIN; +Cc: crossgcc 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* [PATCH 2 of 2] libc/eglibc: [OS X] Don't Redefine Already Defined Types in rpc/types.h 2013-03-26 15:28 [PATCH 0 of 2] [OS X] Fix Compilation of eglibc-2.17 Philip Belemezov 2013-03-26 15:28 ` [PATCH 1 of 2] libc/eglibc: [OS X] Don't Use __block as a Name of an Argument Philip Belemezov @ 2013-03-26 15:28 ` Philip Belemezov 2013-04-12 21:57 ` Yann E. MORIN 1 sibling, 1 reply; 10+ messages in thread From: Philip Belemezov @ 2013-03-26 15:28 UTC (permalink / raw) To: crossgcc # HG changeset patch # User Philip Belemezov <philip@belemezov.net> # Date 1364300929 -7200 # Node ID 0926f7ff958ad637d4727e4e02ed2900ce29291a # Parent fcdf7fc7fd1c00715c3d9651ff00d805ecfb8aa8 libc/eglibc: [OS X] Don't Redefine Already Defined Types in rpc/types.h Apple already defines the u_char, u_short, etc. types in <sys/types.h>. However, those are defined directly, without using the __u_char types. So, don't even try to define those on OS X. Signed-Off-By: Philip Belemezov <philip@belemezov.net> diff -r fcdf7fc7fd1c -r 0926f7ff958a patches/eglibc/2_17/osx_do_not_redefine_types_sunrpc.patch --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/patches/eglibc/2_17/osx_do_not_redefine_types_sunrpc.patch Tue Mar 26 14:28:49 2013 +0200 @@ -0,0 +1,39 @@ +Apple already defines the u_char, u_short, etc. types in <sys/types.h>. +However, those are defined directly, without using the __u_char types. + +diff -Naur eglibc-2_17-old/sunrpc/rpc/types.h eglibc-2_17-new/sunrpc/rpc/types.h +--- eglibc-2_17-old/sunrpc/rpc/types.h 2010-08-19 23:32:31.000000000 +0300 ++++ eglibc-2_17-new/sunrpc/rpc/types.h 2013-03-26 01:16:16.000000000 +0200 +@@ -69,7 +69,11 @@ + #include <sys/types.h> + #endif + +-#ifndef __u_char_defined ++/* ++ * OS X already has these <sys/types.h> ++ */ ++#ifndef __APPLE__ ++# ifndef __u_char_defined + typedef __u_char u_char; + typedef __u_short u_short; + typedef __u_int u_int; +@@ -77,13 +81,14 @@ + typedef __quad_t quad_t; + typedef __u_quad_t u_quad_t; + typedef __fsid_t fsid_t; +-# define __u_char_defined +-#endif +-#ifndef __daddr_t_defined ++# define __u_char_defined ++# endif ++# ifndef __daddr_t_defined + typedef __daddr_t daddr_t; + typedef __caddr_t caddr_t; +-# define __daddr_t_defined +-#endif ++# define __daddr_t_defined ++# endif ++#endif /* __APPLE__ */ + + #include <sys/time.h> + #include <sys/param.h> -- For unsubscribe information see http://sourceware.org/lists.html#faq ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH 2 of 2] libc/eglibc: [OS X] Don't Redefine Already Defined Types in rpc/types.h 2013-03-26 15:28 ` [PATCH 2 of 2] libc/eglibc: [OS X] Don't Redefine Already Defined Types in rpc/types.h Philip Belemezov @ 2013-04-12 21:57 ` Yann E. MORIN 2013-04-13 6:29 ` Titus von Boxberg 2013-04-13 16:10 ` Philip Belemezov 0 siblings, 2 replies; 10+ messages in thread From: Yann E. MORIN @ 2013-04-12 21:57 UTC (permalink / raw) To: Philip Belemezov; +Cc: crossgcc Philip, All, On Tue, Mar 26, 2013 at 05:25:32PM +0200, Philip Belemezov wrote: > # HG changeset patch > # User Philip Belemezov <philip@belemezov.net> > # Date 1364300929 -7200 > # Node ID 0926f7ff958ad637d4727e4e02ed2900ce29291a > # Parent fcdf7fc7fd1c00715c3d9651ff00d805ecfb8aa8 > libc/eglibc: [OS X] Don't Redefine Already Defined Types in rpc/types.h > > Apple already defines the u_char, u_short, etc. types in <sys/types.h>. > However, those are defined directly, without using the __u_char types. Ditto your previous patch. Regards, Yann E. MORIN. -- .-----------------.--------------------.------------------.--------------------. | Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: | | +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ | | +33 223 225 172 `------------.-------: X AGAINST | \e/ There is no | | http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. | '------------------------------^-------^------------------^--------------------' -- For unsubscribe information see http://sourceware.org/lists.html#faq ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH 2 of 2] libc/eglibc: [OS X] Don't Redefine Already Defined Types in rpc/types.h 2013-04-12 21:57 ` Yann E. MORIN @ 2013-04-13 6:29 ` Titus von Boxberg 2013-04-13 16:10 ` Philip Belemezov 1 sibling, 0 replies; 10+ messages in thread From: Titus von Boxberg @ 2013-04-13 6:29 UTC (permalink / raw) To: crossgcc Am 12.04.2013 23:57, schrieb Yann E. MORIN: > Philip, All, > > On Tue, Mar 26, 2013 at 05:25:32PM +0200, Philip Belemezov wrote: >> # HG changeset patch >> # User Philip Belemezov <philip@belemezov.net> >> # Date 1364300929 -7200 >> # Node ID 0926f7ff958ad637d4727e4e02ed2900ce29291a >> # Parent fcdf7fc7fd1c00715c3d9651ff00d805ecfb8aa8 >> libc/eglibc: [OS X] Don't Redefine Already Defined Types in rpc/types.h >> >> Apple already defines the u_char, u_short, etc. types in <sys/types.h>. >> However, those are defined directly, without using the __u_char types. > > Ditto your previous patch. Yann, Philip, All, please have a look at http://cygwin.com/ml/crossgcc/2011-02/msg00025.html Maybe it helps to integrate Philip's issues with those (yet unapplied) patches. Regards Titus -- For unsubscribe information see http://sourceware.org/lists.html#faq ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH 2 of 2] libc/eglibc: [OS X] Don't Redefine Already Defined Types in rpc/types.h 2013-04-12 21:57 ` Yann E. MORIN 2013-04-13 6:29 ` Titus von Boxberg @ 2013-04-13 16:10 ` Philip Belemezov 1 sibling, 0 replies; 10+ messages in thread From: Philip Belemezov @ 2013-04-13 16:10 UTC (permalink / raw) To: Yann E. MORIN; +Cc: crossgcc On 13.04.2013 00:57, Yann E. MORIN wrote: > Philip, All, > > On Tue, Mar 26, 2013 at 05:25:32PM +0200, Philip Belemezov wrote: >> # HG changeset patch >> # User Philip Belemezov <philip@belemezov.net> >> # Date 1364300929 -7200 >> # Node ID 0926f7ff958ad637d4727e4e02ed2900ce29291a >> # Parent fcdf7fc7fd1c00715c3d9651ff00d805ecfb8aa8 >> libc/eglibc: [OS X] Don't Redefine Already Defined Types in rpc/types.h >> >> Apple already defines the u_char, u_short, etc. types in <sys/types.h>. >> However, those are defined directly, without using the __u_char types. > > Ditto your previous patch. > > Regards, > Yann E. MORIN. > Yann, here's the error that lead me to create the above patch: [ALL ] x86_64-build_apple-darwin12.2.1-gcc -D_RPC_THREAD_SAFE_ -D_GNU_SOURCE -DIS_IN_build -include /Volumes/cross-disk/test-osx/.build/armv6-rpi-linux-gnueabihf/build/build-libc-startfiles/config.h rpc_parse.c -o /Volumes/cross-disk/test-osx/.build/armv6-rpi-linux-gnueabihf/build/build-libc-startfiles/sunrpc/cross-rpc_parse.o -MMD -MP -MF /Volumes/cross-disk/test-osx/.build/armv6-rpi-linux-gnueabihf/build/build-libc-startfiles/sunrpc/cross-rpc_parse.o.dt -MT /Volumes/cross-disk/test-osx/.build/armv6-rpi-linux-gnueabihf/build/build-libc-startfiles/sunrpc/cross-rpc_parse.o -c [ALL ] mkdir /Volumes/cross-disk/test-osx/armv6-rpi-linux-gnueabihf/armv6-rpi-linux-gnueabihf/sysroot/usr/include/nfs [ALL ] /Volumes/cross-disk/test-osx/.build/tools/bin/install -c -m 644 ../sysdeps/unix/sysv/linux/nfs/nfs.h /Volumes/cross-disk/test-osx/armv6-rpi-linux-gnueabihf/armv6-rpi-linux-gnueabihf/sysroot/usr/include/nfs/nfs.h [ALL ] x86_64-build_apple-darwin12.2.1-gcc -D_RPC_THREAD_SAFE_ -D_GNU_SOURCE -DIS_IN_build -include /Volumes/cross-disk/test-osx/.build/armv6-rpi-linux-gnueabihf/build/build-libc-startfiles/config.h rpc_scan.c -o /Volumes/cross-disk/test-osx/.build/armv6-rpi-linux-gnueabihf/build/build-libc-startfiles/sunrpc/cross-rpc_scan.o -MMD -MP -MF /Volumes/cross-disk/test-osx/.build/armv6-rpi-linux-gnueabihf/build/build-libc-startfiles/sunrpc/cross-rpc_scan.o.dt -MT /Volumes/cross-disk/test-osx/.build/armv6-rpi-linux-gnueabihf/build/build-libc-startfiles/sunrpc/cross-rpc_scan.o -c [ALL ] In file included from rpc_parse.c:39: [ERROR] rpc/types.h:73: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'u_char' [ERROR] rpc/types.h:74: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'u_short' [ERROR] rpc/types.h:75: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'u_int' [ERROR] rpc/types.h:76: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'u_long' [ERROR] rpc/types.h:77: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'quad_t' [ERROR] rpc/types.h:78: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'u_quad_t' [ERROR] rpc/types.h:79: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'fsid_t' [ERROR] rpc/types.h:83: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'daddr_t' [ERROR] rpc/types.h:84: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'caddr_t' [ALL ] In file included from rpc_main.c:51: [ALL ] proto.h:63:1: warning: "textdomain" redefined [ALL ] In file included from rpc_main.c:41: [ALL ] /usr/local/include/libintl.h:259:1: warning: this is the location of the previous definition [ALL ] In file included from rpc_scan.c:44: [ALL ] proto.h:63:1: warning: "textdomain" redefined [ALL ] In file included from rpc_scan.c:40: [ALL ] /usr/local/include/libintl.h:259:1: warning: this is the location of the previous definition [ERROR] make[3]: *** [/Volumes/cross-disk/test-osx/.build/armv6-rpi-linux-gnueabihf/build/build-libc-startfiles/sunrpc/cross-rpc_parse.o] Error 1 [ALL ] make[3]: *** Waiting for unfinished jobs.... [ERROR] make[2]: *** [sunrpc/install-headers] Error 2 [ERROR] make[1]: *** [install-headers] Error 2 [ERROR] [ERROR] >> [ERROR] >> Build failed in step 'Installing C library headers & start files' [ERROR] >> called in step '(top-level)' [ERROR] >> [ERROR] >> Error happened in: CT_DoExecLog[scripts/functions@216] [ERROR] >> called from: do_libc_backend_once[scripts/build/libc/glibc-eglibc.sh-common@380] [ERROR] >> called from: do_libc_backend[scripts/build/libc/glibc-eglibc.sh-common@143] [ERROR] >> called from: do_libc_start_files[scripts/build/libc/glibc-eglibc.sh-common@60] [ERROR] >> called from: main[scripts/crosstool-NG.sh@632] -- Philip -- For unsubscribe information see http://sourceware.org/lists.html#faq ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2013-04-14 8:13 UTC | newest] Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2013-03-26 15:28 [PATCH 0 of 2] [OS X] Fix Compilation of eglibc-2.17 Philip Belemezov 2013-03-26 15:28 ` [PATCH 1 of 2] libc/eglibc: [OS X] Don't Use __block as a Name of an Argument Philip Belemezov 2013-04-12 21:51 ` Yann E. MORIN 2013-04-13 4:48 ` Philip Belemezov 2013-04-13 9:56 ` Yann E. MORIN 2013-04-14 8:13 ` Philip Belemezov 2013-03-26 15:28 ` [PATCH 2 of 2] libc/eglibc: [OS X] Don't Redefine Already Defined Types in rpc/types.h Philip Belemezov 2013-04-12 21:57 ` Yann E. MORIN 2013-04-13 6:29 ` Titus von Boxberg 2013-04-13 16:10 ` Philip Belemezov
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).