libtool-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: powerpc*le-linux support


From: Peter Rosin
Subject: Re: powerpc*le-linux support
Date: Thu, 22 Aug 2013 13:16:04 +0200
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7

On 2013-08-22 10:19, Gary V. Vaughan wrote:
> On Aug 22, 2013, at 2:59 PM, Peter Rosin <address@hidden> wrote:
>> On 2013-06-06 07:18, Alan Modra wrote:

*snip*

>>> diff --git a/m4/libtool.m4 b/m4/libtool.m4
>>> index d7013c5..501246d 100644
>>> --- a/m4/libtool.m4
>>> +++ b/m4/libtool.m4
>>> @@ -1307,7 +1307,7 @@ ia64-*-hpux*)
>>>   rm -rf conftest*
>>>   ;;
>>>
>>> -x86_64-*kfreebsd*-gnu|x86_64-*linux*|ppc*-*linux*|powerpc*-*linux*| \
>>> +x86_64-*kfreebsd*-gnu|x86_64-*linux*|powerpc*-*linux*| \
>>> s390*-*linux*|s390*-*tpf*|sparc*-*linux*)
>>>   # Find out which ABI we are using.
>>>   echo 'int i;' > conftest.$ac_ext
>>> @@ -1328,7 +1328,10 @@ s390*-*linux*|s390*-*tpf*|sparc*-*linux*)
>>>             ;;
>>>         esac
>>>         ;;
>>> -     ppc64-*linux*|powerpc64-*linux*)
>>> +     powerpc64le-*)
>>> +       LD="${LD-ld} -m elf32lppclinux"
>>> +       ;;
>>> +     powerpc64-*)
>>>         LD="${LD-ld} -m elf32ppclinux"
>>>         ;;
>>>       s390x-*linux*)

*snip*

>> This also made me think
>> about the 32-bit case; is there no le variant for 32-bit powerpc?
>> Compare with the x86_64 case just above this hunk. To me, it seems as
>> if -m elf32lppclinux should be added to $LD at least in some case?
> 
> That's only because I fumbled the initial commit.  The original patch
> catches ppcle on 32 and 64 bit legs of that case statement.

No, that's no what I meant at all, my above paragraph was about the
same issue as my below paragraph (your munged commit just happened to
inconveniently fit the description).

>> When you build 32-bit output and $host is 64-bit, you need to specify
>> endianess (elf32lppclinux or elf32ppclinux). When you build 64-bit
>> output and $host is 64-bit, you need to specify endianess (elf64lppc
>> or elf64ppc). I miss the case when you build 32-bit output and $host
>> is 32-bit, i.e. something like the below (assuming $host is
>> powerpcle-* and powerpc-* for 32-bit) at the end of the second hunk:
>>
>> +      powerpcle-*linux*)
>> +        LD="${LD-ld} -m elf32lppclinux"
>> +        ;;
>> +      powerpc-*linux*)
>> +        LD="${LD-ld} -m elf32ppclinux"
>> +        ;;
>>
>> If there is no 32-bit le powerpc variant (why wouldn't there be?), then
>> the subject is somewhat misleading when le is only handled for 64-bit
>> hosts.

I guess I'm just thoroughly confused, but in my world there ought to
be four variations of $host; 64- or 32-bit, and big or little endian.

This patch seems to only handle builds going from 64-bit to 32-bit
($host powerpc64-* and 32-bit output) and compiles going from 32-bit
to 64-bit ($host powerpc-* and 64-bit output).

Both of those cases ought to be cross compiles. But I don't get why you
apparently do not need to give any -m option to ld when you cross-compile
from 32-bit little-endian to 32-bit big-endian and from 64-bit l-e to
64-bit b-e? Is the user required to provide the appropriate -m option
manually in that case? Why is it important to be more helpful for
crosses over the 32/64 boundary?

Sorry for my ppc ignorance...

*snip*

Cheers,
Peter




reply via email to

[Prev in Thread] Current Thread [Next in Thread]