public inbox for gentoo-soc@lists.gentoo.org
 help / color / mirror / Atom feed
From: Luca Barbato <lu_zero@gentoo.org>
To: gentoo-soc@lists.gentoo.org
Subject: Re: [gentoo-soc] Gentoo on Android, Summary for 2013.6.28-7.1
Date: Sun, 18 Aug 2013 14:29:32 +0200	[thread overview]
Message-ID: <5210BE2C.3010407@gentoo.org> (raw)
In-Reply-To: <871u5r19fj.fsf@proton.in.awa.tohoku.ac.jp>

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


  reply	other threads:[~2013-08-18 12:29 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-01 14:48 [gentoo-soc] Gentoo on Android, Summary for 2013.6.28-7.1 heroxbd
2013-07-01 14:59 ` Luca Barbato
2013-07-01 15:18   ` heroxbd
2013-07-01 15:27     ` Luca Barbato
2013-07-22  7:19       ` Benda Xu
2013-07-22 12:01         ` Luca Barbato
2013-07-22 12:24           ` heroxbd
2013-07-22 12:32             ` Luca Barbato
2013-08-18 12:16               ` heroxbd
2013-08-18 12:29                 ` Luca Barbato [this message]
2013-08-18 13:17                   ` heroxbd

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5210BE2C.3010407@gentoo.org \
    --to=lu_zero@gentoo.org \
    --cc=gentoo-soc@lists.gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox