[PATCH 0 of 2] [OS X] Fix Compilation of eglibc-2.17

[PATCH 0 of 2] [OS X] Fix Compilation of eglibc-2.17

[Philip Belemezov]

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

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

[Philip Belemezov]

# 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

[PATCH 2 of 2] libc/eglibc: [OS X] Don't Redefine Already Defined Types in rpc/types.h

[Philip Belemezov]

# 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

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

[Yann E. MORIN]

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

Re: [PATCH 2 of 2] libc/eglibc: [OS X] Don't Redefine Already Defined Types in rpc/types.h

[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.

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

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

[Philip Belemezov]

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

Re: [PATCH 2 of 2] libc/eglibc: [OS X] Don't Redefine Already Defined Types in rpc/types.h

[Titus von Boxberg]

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

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

[Yann E. MORIN]

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

Re: [PATCH 2 of 2] libc/eglibc: [OS X] Don't Redefine Already Defined Types in rpc/types.h

[Philip Belemezov]

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

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

[Philip Belemezov]

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