[gentoo-soc] Gentoo on Android, Summary for 2013.6.28-7.1

[gentoo-soc] Gentoo on Android, Summary for 2013.6.28-7.1

[heroxbd]

Dear Guys and Gals,

Gentoo on Android is about running Gentoo natively in a directory prefix
on Android devices[1] in parallel with native Android, mentored by Luca.

Progress report for the past 3 days,

     1. gcc specs hack is not that interesting as it first looks.
        - parsing or generating specs script is no fun.
          The best parser/generator is gcc itself
        - appending simple specs (suches -dynamic-linker=/xx/xx.so) feel
          not clever, appending --with-spec to configure either.

        Therefore, I decide not to use specs hack as the main building
        block. At the same time, it can be handy to do manual tuning
        with it.
     
        Relying on binutils wrapper is no good either. The solution
        finally falls on a mixed one between sysroot and native paths
        methods (ref. table in [2]). Where I make use of eprefixify of
        prefix.eclass to modify location of dynamic linker for *run
        time* and sysroot for *compile time*.

     2. Prefix/libc armhf works rock solid. It is now being "emerge -e
        @world" with the help of many distcc cross compilers. I have to
        leave my cell phone home for a constant power supply and
        ethernet connection (yes! USB ethernet adapter) though.

     3. A problem on RHEL 5.6 made me question how far could I go with
        ancient GNU/Linux environments. 

        gcc bootstrap fails horribly in stage2

,----
| /dev/shm/portage/sys-devel/gcc-4.7.2-r1/work/build/gcc $ ./cc1
| cc1: internal compiler error: Segmentation fault
| Please submit a full bug report,
| with preprocessed source if appropriate.
| See <http://bugs.gentoo.org/> for instructions.
`----

        The bug is related to VDSO. A full description of the problem is
        on stackoverflow[3]. I'd be very appreciated for any hints.

So much for today. Cheers!
Benda

1. http://www.awa.tohoku.ac.jp/~benda/projects/android.html
2. http://wiki.gentoo.org/wiki/Prefix/libc
3. http://stackoverflow.com/questions/17406389/is-it-possible-to-turn-off-vdso-on-glibc-side

Re: [gentoo-soc] Gentoo on Android, Summary for 2013.6.28-7.1

[Luca Barbato]

On 07/01/2013 04:48 PM, heroxbd wrote:
> Dear Guys and Gals,
> 
> Gentoo on Android is about running Gentoo natively in a directory prefix
> on Android devices[1] in parallel with native Android, mentored by Luca.
> 
> Progress report for the past 3 days,
> 
>      1. gcc specs hack is not that interesting as it first looks.
>         - parsing or generating specs script is no fun.
>           The best parser/generator is gcc itself
>         - appending simple specs (suches -dynamic-linker=/xx/xx.so) feel
>           not clever, appending --with-spec to configure either.
> 
>         Therefore, I decide not to use specs hack as the main building
>         block. At the same time, it can be handy to do manual tuning
>         with it.

That must be reconsidered later to understand what's the problem and if
upstream can help on that.

>         Relying on binutils wrapper is no good either. The solution
>         finally falls on a mixed one between sysroot and native paths
>         methods (ref. table in [2]). Where I make use of eprefixify of
>         prefix.eclass to modify location of dynamic linker for *run
>         time* and sysroot for *compile time*.

It isn't perfect, but as long it gives result I can live with that.

>      2. Prefix/libc armhf works rock solid. It is now being "emerge -e
>         @world" with the help of many distcc cross compilers. I have to
>         leave my cell phone home for a constant power supply and
>         ethernet connection (yes! USB ethernet adapter) though.

Make sure it is near a heatsink (AC or such).

>         The bug is related to VDSO. A full description of the problem is
>         on stackoverflow[3]. I'd be very appreciated for any hints.

uclibc or musl might or might not help?

lu

Re: [gentoo-soc] Gentoo on Android, Summary for 2013.6.28-7.1

[heroxbd]

Hey Luca,

Luca Barbato <lu_zero@gentoo.org> writes:

> On 07/01/2013 04:48 PM, heroxbd wrote:
>
>> Gentoo on Android is about running Gentoo natively in a directory prefix
>> on Android devices[1] in parallel with native Android, mentored by Luca.
>> 
>> Progress report for the past 3 days,
>> 
>>      1. gcc specs hack is not that interesting as it first looks.
>>         - parsing or generating specs script is no fun.
>>           The best parser/generator is gcc itself
>>         - appending simple specs (suches -dynamic-linker=/xx/xx.so) feel
>>           not clever, appending --with-spec to configure either.
>> 
>>         Therefore, I decide not to use specs hack as the main building
>>         block. At the same time, it can be handy to do manual tuning
>>         with it.
>
> That must be reconsidered later to understand what's the problem and if
> upstream can help on that.

Got it.

>>         Relying on binutils wrapper is no good either. The solution
>>         finally falls on a mixed one between sysroot and native paths
>>         methods (ref. table in [2]). Where I make use of eprefixify of
>>         prefix.eclass to modify location of dynamic linker for *run
>>         time* and sysroot for *compile time*.
>
> It isn't perfect, but as long it gives result I can live with that.

The perfect solution is to use --with-runtime-root-prefix contributed by
Google[1][2], but not enough interest was gathered[3].

>>      2. Prefix/libc armhf works rock solid. It is now being "emerge -e
>>         @world" with the help of many distcc cross compilers. I have to
>>         leave my cell phone home for a constant power supply and
>>         ethernet connection (yes! USB ethernet adapter) though.
>
> Make sure it is near a heatsink (AC or such).

The sensor says it's less than 40 degree C ;)

>>         The bug is related to VDSO. A full description of the problem is
>>         on stackoverflow[3]. I'd be very appreciated for any hints.
>
> uclibc or musl might or might not help?

Not sure, I'm going to try out uclibc/musl anyway.

UPDATE: asked for help on glibc mailing list

        http://article.gmane.org/gmane.comp.lib.glibc.user/1903

Cheers,
Benda

1. http://gcc.gnu.org/ml/gcc-patches/2011-01/msg01904.html
2. http://gcc.gnu.org/ml/gcc-help/2012-03/msg00146.html
3. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52556

Re: [gentoo-soc] Gentoo on Android, Summary for 2013.6.28-7.1

[Luca Barbato]

On 07/01/2013 05:18 PM, heroxbd wrote:
> Hey Luca,
> 
> Luca Barbato <lu_zero@gentoo.org> writes:
> 
>> On 07/01/2013 04:48 PM, heroxbd wrote:
>>
>>> Gentoo on Android is about running Gentoo natively in a directory prefix
>>> on Android devices[1] in parallel with native Android, mentored by Luca.
>>>
>>> Progress report for the past 3 days,
>>>
>>>      1. gcc specs hack is not that interesting as it first looks.
>>>         - parsing or generating specs script is no fun.
>>>           The best parser/generator is gcc itself
>>>         - appending simple specs (suches -dynamic-linker=/xx/xx.so) feel
>>>           not clever, appending --with-spec to configure either.
>>>
>>>         Therefore, I decide not to use specs hack as the main building
>>>         block. At the same time, it can be handy to do manual tuning
>>>         with it.
>>
>> That must be reconsidered later to understand what's the problem and if
>> upstream can help on that.
> 
> Got it.
> 
>>>         Relying on binutils wrapper is no good either. The solution
>>>         finally falls on a mixed one between sysroot and native paths
>>>         methods (ref. table in [2]). Where I make use of eprefixify of
>>>         prefix.eclass to modify location of dynamic linker for *run
>>>         time* and sysroot for *compile time*.
>>
>> It isn't perfect, but as long it gives result I can live with that.
> 
> The perfect solution is to use --with-runtime-root-prefix contributed by
> Google[1][2], but not enough interest was gathered[3].

The patch itself is partially wrong (you might want to use a totally
different layout) but surely looks interesting.

lu

Re: [gentoo-soc] Gentoo on Android, Summary for 2013.6.28-7.1

[Benda Xu]

[-- Attachment #1: Type: text/plain, Size: 485 bytes --]

Dear Luca,

On Tue, Jul 2, 2013 at 12:27 AM, Luca Barbato <lu_zero@gentoo.org> wrote:

>
> The patch itself is partially wrong (you might want to use a totally
> different layout) but surely looks interesting.
>

I'd like to revisit this topic. Could you please be a bit more specific on
where it is partially wrong?

http://gcc.gnu.org/ml/gcc-patches/2011-01/msg01904.html

-- 
XU Benda
Research Center for Neutrino Science
Tohoku University
JAPAN

http://www.awa.tohoku.ac.jp/~benda

[-- Attachment #2: Type: text/html, Size: 1040 bytes --]

Re: [gentoo-soc] Gentoo on Android, Summary for 2013.6.28-7.1

[Luca Barbato]

On 07/22/2013 09:19 AM, Benda Xu wrote:
> Dear Luca,
> 
> On Tue, Jul 2, 2013 at 12:27 AM, Luca Barbato <lu_zero@gentoo.org> wrote:
> 
>>
>> The patch itself is partially wrong (you might want to use a totally
>> different layout) but surely looks interesting.
>>
> 
> I'd like to revisit this topic. Could you please be a bit more specific on
> where it is partially wrong?
> 
> http://gcc.gnu.org/ml/gcc-patches/2011-01/msg01904.html
> 

You have some flavours, e.g.

+#define GLIBC_DYNAMIC_LINKER32 RUNTIME_ROOT_PREFIX "/lib/ld-linux.so.2"
+#define GLIBC_DYNAMIC_LINKER64 RUNTIME_ROOT_PREFIX
"/lib64/ld-linux-x86-64.so.2"

or

+#define UCLIBC_DYNAMIC_LINKER RUNTIME_ROOT_PREFIX "/lib/ld-uClibc.so.0"
+#define UCLIBC_DYNAMIC_LINKER32 RUNTIME_ROOT_PREFIX "/lib/ld-uClibc.so.0"
+#define UCLIBC_DYNAMIC_LINKER64 RUNTIME_ROOT_PREFIX "/lib/ld64-uClibc.so.0"

And you add some prefix to it.

while the correct patch would just wipe all this cruft and have a

DYNAMIC_LINKER_{32/64/default} and a mean to set it.

Everything is still not exactly great since you could have more than 2
abis per architecture.

As said the patch is surely an improvement over the previous situation
but doesn't help solving the problem fully.

lu

Re: [gentoo-soc] Gentoo on Android, Summary for 2013.6.28-7.1

[heroxbd]

Dear Luca,

Luca Barbato <lu_zero@gentoo.org> writes:

> On 07/22/2013 09:19 AM, Benda Xu wrote:
>
> You have some flavours, e.g.
>
> +#define GLIBC_DYNAMIC_LINKER32 RUNTIME_ROOT_PREFIX "/lib/ld-linux.so.2"
> +#define GLIBC_DYNAMIC_LINKER64 RUNTIME_ROOT_PREFIX "/lib64/ld-linux-x86-64.so.2"
>
> or
>
> +#define UCLIBC_DYNAMIC_LINKER RUNTIME_ROOT_PREFIX "/lib/ld-uClibc.so.0"
> +#define UCLIBC_DYNAMIC_LINKER32 RUNTIME_ROOT_PREFIX "/lib/ld-uClibc.so.0"
> +#define UCLIBC_DYNAMIC_LINKER64 RUNTIME_ROOT_PREFIX "/lib/ld64-uClibc.so.0"
>
> And you add some prefix to it.
>
> while the correct patch would just wipe all this cruft and have a
>
> DYNAMIC_LINKER_{32/64/default} and a mean to set it.
>
> Everything is still not exactly great since you could have more than 2
> abis per architecture.
>
> As said the patch is surely an improvement over the previous situation
> but doesn't help solving the problem fully.

Got what you meant. I am just afraid if upstream would reject a mean to
fully override the dynamic linker for the sake of a /absolutely stable
soname/.

An alternative: Given the similar situation in binutils, I am thinking
of another switch (like --{enable,with}-native-sysroot) to turn
--with-sysroot into a native (non-cross) version for our purpose. (GLEP
draft follows) What do you say?

Cheers,
Benda

Re: [gentoo-soc] Gentoo on Android, Summary for 2013.6.28-7.1

[Luca Barbato]

On 07/22/2013 02:24 PM, heroxbd wrote:
> Got what you meant. I am just afraid if upstream would reject a mean to
> fully override the dynamic linker for the sake of a /absolutely stable
> soname/.

Upstream can be difficult, supporting multiple c runtime is _quite_
problematic and requires pointless patching in too many part of the
codebase nowadays =/

> An alternative: Given the similar situation in binutils, I am thinking
> of another switch (like --{enable,with}-native-sysroot) to turn
> --with-sysroot into a native (non-cross) version for our purpose. (GLEP
> draft follows) What do you say?

Worth a try, sadly you need to coordinate with upstream.

Since we are nearing the midterm would be great having an interim
release so people could try the current setup and get and idea easily.

Probably that would help winning more support in discussing with upstream.

lu

Re: [gentoo-soc] Gentoo on Android, Summary for 2013.6.28-7.1

[heroxbd]

Dear Luca,

Picking up gcc again.

Luca Barbato <lu_zero@gentoo.org> writes:

> Upstream can be difficult, supporting multiple c runtime is _quite_
> problematic and requires pointless patching in too many part of the
> codebase nowadays =/

Yes, for example, the *link section of gcc amd64:

*link:

%{!static:--eh-frame-hdr} %{m32|mx32:;:-m elf_x86_64} %{m32:-m elf_i386}
%{ mx32:-m elf32_x86_64} %{shared:-shared} %{!shared: %{!static:
%{rdynamic:-export-dynamic} %{m 32:-dynamic-linker
%{muclibc:/lib/ld-uClibc.so.0;:%{mbionic:/system/bin/linker;:/opt/gentoo/lib/ld-linux.so.2}}}
%{m32|mx32:;:-dynamic-linker
%{muclibc:/lib/ld64-uClibc.so.0;:%{mbionic:/system/bin/linker64;:/opt/gentoo/l
ib64/ld-linux-x86-64.so.2}}} %{mx32:-dynamic-linker
%{muclibc:/lib/ldx32-uClibc.so.0;:%{mbionic:/system/bin
/linkerx32;:/opt/gentoo/libx32/ld-linux-x32.so.2}}}} %{static:-static}}

>> An alternative: Given the similar situation in binutils, I am thinking
>> of another switch (like --{enable,with}-native-sysroot) to turn
>> --with-sysroot into a native (non-cross) version for our purpose. (GLEP
>> draft follows) What do you say?
>
> Worth a try, sadly you need to coordinate with upstream.

I spent a whole day trying to get a solution to specify dynamic
linker via configure.

The plan was:

1. let all the ports of gcc have dynamic_linker section in specs,
like that of x86.

2. add a configure option, --with-extra-specs to specify an
additional EXTRA_SPECS to gcc.c.

3. use toolchain-funcs.eclass to generate dynamic linker specs, as

+# Returns location of dynamic linker
+gcc-specs-gen-dynamic-linker() {
+       echo '*dynamic_linker:'
+
+       local dlinkers
+       case $(tc-arch)-${CTARGET##*-} in
+       amd64-gnu*)
+               for abi in ${MULTILIB_ABIS}; do
+                       case ${abi} in
+                       amd64) dlinkers+=( "m32|mx32:;:/lib64/ld-linux-x86-64.so.2" ) ;;
+                       x86) dlinkers+=( m32:/lib/ld-linux.so.2 ) ;;
+                       x32) dlinkers+=( mx32:/libx32/ld-linux-x32.so.2 ) ;;
+                       esac
+               done
+               ;;
+       x86-gnu*) dlinkers=( /lib/ld-linux.so.2 ) ;;
+       arm-gnu*)
+               case ${CTARGET//_/-} in
+               *-hardfloat-*) dlinkers=( /lib/ld-linux-armhf.so.3 ) ;;
+               *-softfloat-*) dlinkers=( /lib/ld-linux.so.3 ) ;;
+               esac
+               ;;
+       esac
+
+       for dlinker in ${dlinkers[@]}; do
+               local ldso=${dlinker##*:}
+               if [[ ${ldso} == ${dlinker} ]]; then
+                       echo -n "${EPREFIX}"${ldso}
+               else
+                       local switch=${dlinker%:*}
+                       echo -n "%{${switch}:${EPREFIX}${ldso}}"
+               fi
+       done
+}

But there are intrinsic difficulties. The default specs of gcc
are all preprocessed as C macros, which means we cannot pass a
specs file to make it default. Furthermore, I could not find a
way to pass a customized specs file for building (which is
necessary that we have to build gcc against glibc from
RAP). Therefore, we have to pass raw C into configure options,
like,

econf --with-extra-specs='{ "dynamic-linker", "/opt/gentoo/lib/ld-linux.so.2" }'

However, GNU autoconf/automake system automatically quote this to
a string, while we want to pass an array of structures.

Another solution is to prepend sysroot to dynamic linker, which is
indifferent to the runtime-prefix patch from Google, criticized by you
earlier.

Up to this point, the solution becomes complex and artificial. I
would rather use the present patch'n'prefixify method, as we used
in many ebuild, like:

--- gcc/config/i386/linux.h     2011-06-04 03:30:39.000000000 +0900
+++ gcc/config/i386/linux.h.new 2013-07-16 19:55:09.610399047 +0900
@@ -21,4 +21,4 @@ along with GCC; see the file COPYING3.
 <http://www.gnu.org/licenses/>.  */
 
 #define GNU_USER_LINK_EMULATION "elf_i386"
-#define GLIBC_DYNAMIC_LINKER "/lib/ld-linux.so.2"
+#define GLIBC_DYNAMIC_LINKER "@GENTOO_PORTAGE_EPREFIX@/lib/ld-linux.so.2"

Cheers,
Benda

Re: [gentoo-soc] Gentoo on Android, Summary for 2013.6.28-7.1

[Luca Barbato]

On 18/08/13 14:16, heroxbd wrote:
> Dear Luca,
> 
> Picking up gcc again.
> 
> Luca Barbato <lu_zero@gentoo.org> writes:
> 
>> Upstream can be difficult, supporting multiple c runtime is _quite_
>> problematic and requires pointless patching in too many part of the
>> codebase nowadays =/
> 
> Yes, for example, the *link section of gcc amd64:
> 
> *link:
> 
> %{!static:--eh-frame-hdr} %{m32|mx32:;:-m elf_x86_64} %{m32:-m elf_i386}
> %{ mx32:-m elf32_x86_64} %{shared:-shared} %{!shared: %{!static:
> %{rdynamic:-export-dynamic} %{m 32:-dynamic-linker
> %{muclibc:/lib/ld-uClibc.so.0;:%{mbionic:/system/bin/linker;:/opt/gentoo/lib/ld-linux.so.2}}}
> %{m32|mx32:;:-dynamic-linker
> %{muclibc:/lib/ld64-uClibc.so.0;:%{mbionic:/system/bin/linker64;:/opt/gentoo/l
> ib64/ld-linux-x86-64.so.2}}} %{mx32:-dynamic-linker
> %{muclibc:/lib/ldx32-uClibc.so.0;:%{mbionic:/system/bin
> /linkerx32;:/opt/gentoo/libx32/ld-linux-x32.so.2}}}} %{static:-static}}
> 
>>> An alternative: Given the similar situation in binutils, I am thinking
>>> of another switch (like --{enable,with}-native-sysroot) to turn
>>> --with-sysroot into a native (non-cross) version for our purpose. (GLEP
>>> draft follows) What do you say?
>>
>> Worth a try, sadly you need to coordinate with upstream.
> 
> I spent a whole day trying to get a solution to specify dynamic
> linker via configure.
> 
> The plan was:
> 
> 1. let all the ports of gcc have dynamic_linker section in specs,
> like that of x86.
> 
> 2. add a configure option, --with-extra-specs to specify an
> additional EXTRA_SPECS to gcc.c.
> 
> 3. use toolchain-funcs.eclass to generate dynamic linker specs, as
> 
> +# Returns location of dynamic linker
> +gcc-specs-gen-dynamic-linker() {
> +       echo '*dynamic_linker:'
> +
> +       local dlinkers
> +       case $(tc-arch)-${CTARGET##*-} in
> +       amd64-gnu*)
> +               for abi in ${MULTILIB_ABIS}; do
> +                       case ${abi} in
> +                       amd64) dlinkers+=( "m32|mx32:;:/lib64/ld-linux-x86-64.so.2" ) ;;
> +                       x86) dlinkers+=( m32:/lib/ld-linux.so.2 ) ;;
> +                       x32) dlinkers+=( mx32:/libx32/ld-linux-x32.so.2 ) ;;
> +                       esac
> +               done
> +               ;;
> +       x86-gnu*) dlinkers=( /lib/ld-linux.so.2 ) ;;
> +       arm-gnu*)
> +               case ${CTARGET//_/-} in
> +               *-hardfloat-*) dlinkers=( /lib/ld-linux-armhf.so.3 ) ;;
> +               *-softfloat-*) dlinkers=( /lib/ld-linux.so.3 ) ;;
> +               esac
> +               ;;
> +       esac
> +
> +       for dlinker in ${dlinkers[@]}; do
> +               local ldso=${dlinker##*:}
> +               if [[ ${ldso} == ${dlinker} ]]; then
> +                       echo -n "${EPREFIX}"${ldso}
> +               else
> +                       local switch=${dlinker%:*}
> +                       echo -n "%{${switch}:${EPREFIX}${ldso}}"
> +               fi
> +       done
> +}
> 
> But there are intrinsic difficulties. The default specs of gcc
> are all preprocessed as C macros, which means we cannot pass a
> specs file to make it default. Furthermore, I could not find a
> way to pass a customized specs file for building (which is
> necessary that we have to build gcc against glibc from
> RAP). Therefore, we have to pass raw C into configure options,
> like,
> 
> econf --with-extra-specs='{ "dynamic-linker", "/opt/gentoo/lib/ld-linux.so.2" }'
> 
> However, GNU autoconf/automake system automatically quote this to
> a string, while we want to pass an array of structures.

There is an unquote macro and you can always use eval to expand once.

> Another solution is to prepend sysroot to dynamic linker, which is
> indifferent to the runtime-prefix patch from Google, criticized by you
> earlier.

The Google patch is a step in a direction, just you could just unify
first and make it prefix-variable later instead of adding a prefix to
all the custom patches scattered in the codebase as it is now.

> Up to this point, the solution becomes complex and artificial. I
> would rather use the present patch'n'prefixify method, as we used
> in many ebuild, like:
> 
> --- gcc/config/i386/linux.h     2011-06-04 03:30:39.000000000 +0900
> +++ gcc/config/i386/linux.h.new 2013-07-16 19:55:09.610399047 +0900
> @@ -21,4 +21,4 @@ along with GCC; see the file COPYING3.
>  <http://www.gnu.org/licenses/>.  */
>  
>  #define GNU_USER_LINK_EMULATION "elf_i386"
> -#define GLIBC_DYNAMIC_LINKER "/lib/ld-linux.so.2"
> +#define GLIBC_DYNAMIC_LINKER "@GENTOO_PORTAGE_EPREFIX@/lib/ld-linux.so.2"

So first you patch the paths with something you can sed fill later.

Works for me to get a result now. Then we can pester upstream or just
consider switching to clang (a different kind of pain to bootstrap).

lu

Re: [gentoo-soc] Gentoo on Android, Summary for 2013.6.28-7.1

[heroxbd]

Luca Barbato <lu_zero@gentoo.org> writes:

>> 
>> econf --with-extra-specs='{ "dynamic-linker", "/opt/gentoo/lib/ld-linux.so.2" }'
>> 
>> However, GNU autoconf/automake system automatically quote this to
>> a string, while we want to pass an array of structures.
>
> There is an unquote macro and you can always use eval to expand once.

Ah, I see. 

>> Another solution is to prepend sysroot to dynamic linker, which is
>> indifferent to the runtime-prefix patch from Google, criticized by you
>> earlier.
>
> The Google patch is a step in a direction, just you could just unify
> first and make it prefix-variable later 

Not sure if I understood your words. It is nearly impossible to
prefixify the directories afterwards, as they are conditioned by
-m32/-m64/-mx32, etc.

> instead of adding a prefix to all the custom patches scattered in the
> codebase as it is now.


>> Up to this point, the solution becomes complex and artificial. I
>> would rather use the present patch'n'prefixify method, as we used
>> in many ebuild, like:
>> 
>> --- gcc/config/i386/linux.h     2011-06-04 03:30:39.000000000 +0900
>> +++ gcc/config/i386/linux.h.new 2013-07-16 19:55:09.610399047 +0900
>> @@ -21,4 +21,4 @@ along with GCC; see the file COPYING3.
>>  <http://www.gnu.org/licenses/>.  */
>>  
>>  #define GNU_USER_LINK_EMULATION "elf_i386"
>> -#define GLIBC_DYNAMIC_LINKER "/lib/ld-linux.so.2"
>> +#define GLIBC_DYNAMIC_LINKER "@GENTOO_PORTAGE_EPREFIX@/lib/ld-linux.so.2"
>
> So first you patch the paths with something you can sed fill later.

Yes.

> Works for me to get a result now. Then we can pester upstream 

Exactly, http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52556

> or just consider switching to clang (a different kind of pain to
> bootstrap).

ok, I'll get my hands dirty with it.