From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 804A81381F3 for ; Sun, 18 Aug 2013 12:29:40 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 0D651E0B0D; Sun, 18 Aug 2013 12:29:40 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 79B5DE0B0D for ; Sun, 18 Aug 2013 12:29:39 +0000 (UTC) Received: from [192.168.0.90] (dynamic-adsl-84-220-77-144.clienti.tiscali.it [84.220.77.144]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: lu_zero) by smtp.gentoo.org (Postfix) with ESMTPSA id 4E4E333E917 for ; Sun, 18 Aug 2013 12:29:38 +0000 (UTC) Message-ID: <5210BE2C.3010407@gentoo.org> Date: Sun, 18 Aug 2013 14:29:32 +0200 From: Luca Barbato User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130411 Thunderbird/17.0.5 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-soc@lists.gentoo.org Reply-to: gentoo-soc@lists.gentoo.org MIME-Version: 1.0 To: gentoo-soc@lists.gentoo.org Subject: Re: [gentoo-soc] Gentoo on Android, Summary for 2013.6.28-7.1 References: <87mwq6mj4v.fsf@proton.in.awa.tohoku.ac.jp> <51D1995A.8050707@gentoo.org> <87bo6mmhqj.fsf@proton.in.awa.tohoku.ac.jp> <51D19FDF.9080004@gentoo.org> <51ED1EFC.7070607@gentoo.org> <87ppuabx4k.fsf@proton.in.awa.tohoku.ac.jp> <51ED266A.7090400@gentoo.org> <871u5r19fj.fsf@proton.in.awa.tohoku.ac.jp> In-Reply-To: <871u5r19fj.fsf@proton.in.awa.tohoku.ac.jp> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Archives-Salt: 13a69393-4d4b-480b-8504-94e14c0607f2 X-Archives-Hash: 780b6179fa96396d3e486fe6945d2da1 On 18/08/13 14:16, heroxbd wrote: > Dear Luca, > > Picking up gcc again. > > Luca Barbato 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. > . */ > > #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