On Sat, Apr 23, 2016 at 2:16 PM, Mike Frysinger <vap...@gentoo.org> wrote:
> On 22 Apr 2016 03:44, Leno Hou wrote: > > 2) The problem is due to the wrong $LD="ld -m elf64ppc" when link. > > This patch sets $LD="ld -m elf64lppc" in m4/libtool.m4 on ppc64le. > > i'm looking at the upstream libtool project and i'm not seeing > these changes in there. have you sent patches to them to update > libtool ? otherwise, all packages will continue to be created > with bad versions in them ... > > 1) I have reported the libtool in upstream. See here http://debbugs.gnu.org/cgi/bugreport.cgi?bug=23348 2) The new PATCH V3 which called [gentoo-dev][PATCH V3] libtool.eclass:elibtoolize: add ppc64le handling #580792 was sent to mailing list and cc'ed you has update libtool-2.4.6 what upstream has right now is: > if AC_TRY_EVAL(ac_compile); then > case `/usr/bin/file conftest.o` in > *32-bit*) > case $host in > ... > powerpc64le-*linux*) > LD="${LD-ld} -m elf32lppclinux" > ;; > powerpc64-*linux*) > LD="${LD-ld} -m elf32ppclinux" > ;; > ... > *64-bit*) > case $host in > ... > powerpcle-*linux*) > LD="${LD-ld} -m elf64lppc" > ;; > powerpc-*linux*) > LD="${LD-ld} -m elf64ppc" > ;; > ... > > your 2.4.2 patch makes sense in that it had no LE support, so you > need to add the tuple matching. however, the 2.4.4 & 2.4.6 patches > are applying to libtool versions that know how to handle LE. > 3) The 2.4.4 and 2.4.6 are applied correct lib tool version that know how to handle LE > keep in mind that the logic here is just for handling mismatch in > the expected bitness and the tuple. i.e. when you're using a tuple > like powerpc-linux-gnu (which is normally 32bit) but you're actually > producing 64-bit code. > 4) Is tuple .... powerpcle-*linux*) LD="${LD-ld} -m elf64lppc" should be changed to .... powerpcle-*linux*) LD="${LD-ld} -m elf32lppc" to producing 32-bit code? If yes, I'll send new PATCH to cover this. -Leno Hou
