[prev in list] [next in list] [prev in thread] [next in thread]
List: gentoo-dev
Subject: Re: [gentoo-dev][PATCH v2 1/2] eclass/libtool: fix unable read SONAME for ppc64le #580792
From: Leno Hou <lenohou () gmail ! com>
Date: 2016-04-24 11:31:30
Message-ID: CAGQVrL_USJT=R6FeMQTxit-FL4mEUUK0TU6mt2=EN91gmWc_Ow () mail ! gmail ! com
[Download RAW message or body]
On Sat, Apr 23, 2016 at 2:16 PM, Mike Frysinger <vapier@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
[Attachment #3 (text/html)]
<div dir="ltr"><div class="gmail_extra"><div><div class="gmail_signature"><div \
dir="ltr"><div dir="ltr"><br></div></div></div></div><div class="gmail_quote">On Sat, \
Apr 23, 2016 at 2:16 PM, Mike Frysinger <span dir="ltr"><<a \
href="mailto:vapier@gentoo.org" target="_blank">vapier@gentoo.org</a>></span> \
wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span \
class="">On 22 Apr 2016 03:44, Leno Hou wrote:<br> > 2) The problem is due to \
the wrong $LD="ld -m elf64ppc" when link.<br> > This patch sets \
$LD="ld -m elf64lppc" in m4/libtool.m4 on ppc64le.<br> <br>
</span>i'm looking at the upstream libtool project and i'm not seeing<br>
these changes in there. have you sent patches to them to update<br>
libtool ? otherwise, all packages will continue to be created<br>
with bad versions in them ...<br>
<br></blockquote><div><br></div><div>1) I have reported the libtool in upstream. See \
here</div><div><a href="http://debbugs.gnu.org/cgi/bugreport.cgi?bug=23348">http://debbugs.gnu.org/cgi/bugreport.cgi?bug=23348</a><br></div><div><br></div><div>2) \
The new PATCH V3 which called</div><div> [gentoo-dev][PATCH V3] \
libtool.eclass:elibtoolize: add ppc64le handling #580792</div><div> was sent to \
mailing list and cc'ed you</div><div> has update \
libtool-2.4.6</div><div><br></div><blockquote class="gmail_quote" style="margin:0px \
0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
what upstream has right now is:<br>
if AC_TRY_EVAL(ac_compile); then<br>
case `/usr/bin/file conftest.o` in<br>
*32-bit*)<br>
case $host in<br>
...<br>
powerpc64le-*linux*)<br>
<span class=""> LD="${LD-ld} -m elf32lppclinux"<br>
</span> ;;<br>
powerpc64-*linux*)<br>
<span class=""> LD="${LD-ld} -m elf32ppclinux"<br>
</span> ;;<br>
...<br>
*64-bit*)<br>
case $host in<br>
...<br>
powerpcle-*linux*)<br>
<span class=""> LD="${LD-ld} -m elf64lppc"<br>
</span> ;;<br>
powerpc-*linux*)<br>
<span class=""> LD="${LD-ld} -m elf64ppc"<br>
</span> ;;<br>
...<br>
<br>
your 2.4.2 patch makes sense in that it had no LE support, so you<br>
need to add the tuple matching. however, the 2.4.4 & 2.4.6 patches<br>
are applying to libtool versions that know how to handle \
LE.<br></blockquote><div><br></div><div>3) The 2.4.4 and 2.4.6 are applied correct \
lib tool version that know how to handle LE <br></div><div> </div><blockquote \
class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
keep in mind that the logic here is just for handling mismatch in<br>
the expected bitness and the tuple. i.e. when you're using a tuple<br>
like powerpc-linux-gnu (which is normally 32bit) but you're actually<br>
producing 64-bit code.<br></blockquote><div><br></div><div>4) Is tuple \
</div><div> ....</div><div> powerpcle-*linux*)</div><span class=""> \
LD="${LD-ld} -m elf64lppc"</span><div> </div><div> should be \
changed to</div><div> ....</div><div> powerpcle-*linux*)</div><div> \
LD="${LD-ld} -m elf32lppc"</div><div> </div><div> to producing \
32-bit code?</div><div><br></div><div> If yes, I'll send new PATCH to cover \
this. </div><div><br></div><div>-Leno Hou</div></div></div></div>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic