Re: Two-month patch ping: Re: powerpc*le-linux support
On Fri, Aug 23, 2013 at 10:39:42AM +0200, Peter Rosin wrote: > On 2013-08-22 17:48, Alan Modra wrote: > > On Thu, Aug 22, 2013 at 09:34:10PM +0700, Gary V. Vaughan wrote: > >>> How can it be correct to say "-m elf32lppclinux" (32-bit) when $host is > >>> explicitly 64-bit? That seems like utter garbage to me. What am I > >>> missing this time? > > > > As far as I understand, this piece of libtool is supplying ld options > > when your host compiler defaults to something other than what $host > > implies. Which sounds very strange, but consider that on a > > powerpc64-linux host your gcc will usually compile to both 32-bit and > > 64-bit objects. Both 32-bit and 64-bit objects will run on the host, > > and whether gcc produces 32-bit by default (most common a few years > > ago) or 64-bit (most common now), depends on how gcc was configured. > > > > So if $host is powerpc64-linux and $CC is gcc and gcc produces 64-bit > > by default, and $LD is powerpc64-linux-ld then no ld options are > > needed. When generating 32-bit libraries on this system, $host is > > powerpc-linux, $CC is still gcc, and $LD may be powerpc-linux-ld. > > That's a problem because $CC with no options produces 64-bit objects > > but $LD with no options is expecting 32-bit. > > > > This is all somewhat of a guess on my part, but I've seen these $LD > > and $CC selections. Most configure scripts seem to prefer > > "powerpc64-linux-ld" over plain "ld" when $host is powerpc64-linux, > > and similarly "powerpc-linux-ld" for $host of powerpc-linux. > > Sheesh. You are lying about $host, and get to keep all the pieces when You're jumping to a completely wrong conclusion. No "lying", avoiding cross-compilation or any such thing. Just a bi-arch compiler. The same $CC for native powerpc64-linux and a powerpc64-linux to powerpc-linux cross. Why don't *you* do some digging to see what this code is about? Obviously my explanation, which as I said is somewhat of a guess, missed the mark. -- Alan Modra Australia Development Lab, IBM
Re: Two-month patch ping: Re: powerpc*le-linux support
On 2013-08-22 17:48, Alan Modra wrote: > On Thu, Aug 22, 2013 at 09:34:10PM +0700, Gary V. Vaughan wrote: >>> How can it be correct to say "-m elf32lppclinux" (32-bit) when $host is >>> explicitly 64-bit? That seems like utter garbage to me. What am I >>> missing this time? > > As far as I understand, this piece of libtool is supplying ld options > when your host compiler defaults to something other than what $host > implies. Which sounds very strange, but consider that on a > powerpc64-linux host your gcc will usually compile to both 32-bit and > 64-bit objects. Both 32-bit and 64-bit objects will run on the host, > and whether gcc produces 32-bit by default (most common a few years > ago) or 64-bit (most common now), depends on how gcc was configured. > > So if $host is powerpc64-linux and $CC is gcc and gcc produces 64-bit > by default, and $LD is powerpc64-linux-ld then no ld options are > needed. When generating 32-bit libraries on this system, $host is > powerpc-linux, $CC is still gcc, and $LD may be powerpc-linux-ld. > That's a problem because $CC with no options produces 64-bit objects > but $LD with no options is expecting 32-bit. > > This is all somewhat of a guess on my part, but I've seen these $LD > and $CC selections. Most configure scripts seem to prefer > "powerpc64-linux-ld" over plain "ld" when $host is powerpc64-linux, > and similarly "powerpc-linux-ld" for $host of powerpc-linux. Sheesh. You are lying about $host, and get to keep all the pieces when it breaks. If you have host=powerpc64le-*, but the compiler produces powerpcle-* output, then why on earth didn't you say host=powerpcle-* from the beginning? And when there is an obvious mismatch between $host and the compiler output, that seems like a reason to abort to me, and not a reason to use the obviously wrong value of $host to infer something about what the compiler produces and spread the lie to ld. I mean, if the compiler produces powerpcle output and $host matches powerpc64-*, it is just dead wrong to feed -m elf32ppclinux to ld. And similar for other three cases of crossing both the 32/64 boundary and the endian boundary. Taking one example I know of (I'm sure there are plenty), my Octave will print this (among other things) when it starts up: Octave was configured for "i686-pc-cygwin". I bet this is just a copy of $host. If you lie about $host when you build software, that lie is going to spread like mad. So, there are multiple reasons why this model is not sane. The only sane model is to trust $host. If you are building for 32le, say host=powerpcle-* If you are building for 32be, say host=powerpc-* If you are building for 64le, say host=powerpc64le-* If you are building for 64be, say host=powerpc64-* If you then want to avoid the cross-compile mode of autotools (which is what all this boils down to, methinks), it is probably better to lie about $build, it is not used nearly as much as $host. I realize that it is probably too late for the above. Sad. And I haven't tried any of it either, so no doubt it's going to fail in some spectacular way, but it seems much saner to me... Given all the pain the "avoid cross-compile mode at all costs" mentality is causing, it would be really nice if autotools could be taught (or told how) to run run-time checks even in cross-compile mode, whenever that is possible to do as in cases like this. Crosses to MinGW from Cygwin or *ix with Wine come to mind as other examples when people lie about $host/$build to evade the cross-compile mode. Cheers, Peter
Re: [patch] Comments for linker-option section, was Re: powerpc*le-linux support
Hi Brooks, On Aug 23, 2013, at 5:52 AM, Brooks Moses wrote: > Based on Alan's explanation and what I could tell from looking at the code, > I've tried to expand the comments to explain what's going on, as per the > attached patch. Does this look like a useful improvement to the situation? Perfect! And applied. Many thanks. Cheers, -- Gary V. Vaughan (gary AT gnu DOT org) signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Two-month patch ping: Re: powerpc*le-linux support
On Fri, Aug 23, 2013 at 11:10:09AM +0700, Gary V. Vaughan wrote: > Thanks for the explanation, I finally do get it. Phew :) Oh good, because I'm not sure I really understood it despite writing an explanation. :) > I believe I already fixed it with the most recent amendment committed > under your name (exactly by removing the errant * from the case branch > matches). Please pull the most recent revision and let me know if I still > didn't fix everything I broke recently. Thanks! It looks good now. -- Alan Modra Australia Development Lab, IBM
Re: Two-month patch ping: Re: powerpc*le-linux support
Hi Alan, Thanks for the fast feedback. On Aug 22, 2013, at 10:48 PM, Alan Modra wrote: > On Thu, Aug 22, 2013 at 09:34:10PM +0700, Gary V. Vaughan wrote: >>> How can it be correct to say "-m elf32lppclinux" (32-bit) when $host is >>> explicitly 64-bit? That seems like utter garbage to me. What am I >>> missing this time? > > As far as I understand, this piece of libtool is supplying ld options > when your host compiler defaults to something other than what $host > implies. Which sounds very strange, but consider that on a > powerpc64-linux host your gcc will usually compile to both 32-bit and > 64-bit objects. Both 32-bit and 64-bit objects will run on the host, > and whether gcc produces 32-bit by default (most common a few years > ago) or 64-bit (most common now), depends on how gcc was configured. > > So if $host is powerpc64-linux and $CC is gcc and gcc produces 64-bit > by default, and $LD is powerpc64-linux-ld then no ld options are > needed. When generating 32-bit libraries on this system, $host is > powerpc-linux, $CC is still gcc, and $LD may be powerpc-linux-ld. > That's a problem because $CC with no options produces 64-bit objects > but $LD with no options is expecting 32-bit. > > This is all somewhat of a guess on my part, but I've seen these $LD > and $CC selections. Most configure scripts seem to prefer > "powerpc64-linux-ld" over plain "ld" when $host is powerpc64-linux, > and similarly "powerpc-linux-ld" for $host of powerpc-linux. > >> I don't get it either, and I can't test it. Thanks for the explanation, I finally do get it. Phew :) >> I trust the ppcle community >> will commence shouting if the patches have done something horrible. > > It's broken. Please apply exactly the tested patch I submitted, or if > powerpc-* and similar in the switch statement is somehow the wrong > style (we've tested for powerpc*-*linux* already!), then make them > powerpc-*linux*. Not powerpc*-*linux*, which is exactly the same > mistake I made with my first patch.. I believe I already fixed it with the most recent amendment committed under your name (exactly by removing the errant * from the case branch matches). Please pull the most recent revision and let me know if I still didn't fix everything I broke recently. Cheers, -- Gary V. Vaughan (gary AT gnu DOT org) signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Two-month patch ping: Re: powerpc*le-linux support
On Thu, Aug 22, 2013 at 09:34:10PM +0700, Gary V. Vaughan wrote: > > How can it be correct to say "-m elf32lppclinux" (32-bit) when $host is > > explicitly 64-bit? That seems like utter garbage to me. What am I > > missing this time? As far as I understand, this piece of libtool is supplying ld options when your host compiler defaults to something other than what $host implies. Which sounds very strange, but consider that on a powerpc64-linux host your gcc will usually compile to both 32-bit and 64-bit objects. Both 32-bit and 64-bit objects will run on the host, and whether gcc produces 32-bit by default (most common a few years ago) or 64-bit (most common now), depends on how gcc was configured. So if $host is powerpc64-linux and $CC is gcc and gcc produces 64-bit by default, and $LD is powerpc64-linux-ld then no ld options are needed. When generating 32-bit libraries on this system, $host is powerpc-linux, $CC is still gcc, and $LD may be powerpc-linux-ld. That's a problem because $CC with no options produces 64-bit objects but $LD with no options is expecting 32-bit. This is all somewhat of a guess on my part, but I've seen these $LD and $CC selections. Most configure scripts seem to prefer "powerpc64-linux-ld" over plain "ld" when $host is powerpc64-linux, and similarly "powerpc-linux-ld" for $host of powerpc-linux. > I don't get it either, and I can't test it. I trust the ppcle community > will commence shouting if the patches have done something horrible. It's broken. Please apply exactly the tested patch I submitted, or if powerpc-* and similar in the switch statement is somehow the wrong style (we've tested for powerpc*-*linux* already!), then make them powerpc-*linux*. Not powerpc*-*linux*, which is exactly the same mistake I made with my first patch.. -- Alan Modra Australia Development Lab, IBM
Re: Two-month patch ping: Re: powerpc*le-linux support
Hi Peter,
On Aug 22, 2013, at 8:58 PM, Peter Rosin wrote:
> On 2013-08-22 10:20, Gary V. Vaughan wrote:
>> On Aug 22, 2013, at 2:54 PM, Peter Rosin wrote:
>>> On 2013-08-22 09:40, Gary V. Vaughan wrote:
> Can we please get this simple patch pushed?
Done.
>>>
>>> To me, it appears as if what you actually pushed was not what was posted?
>>
>> I am an idiot. Thanks for the heads up, fixed in the following change set.
>
> Still not right though, sorry.
Indeed. I am still an idiot. I am the one who needs to apologise here, thank
you for paying attention and catching it so quickly.
Note to self: make sure to only apply patches directly from emails from now on.
> You ended up doing:
>
> - ppc64-*linux*|powerpc64-*linux*)
> + powerpcle-*)
> + LD="${LD-ld} -m elf32lppclinux"
> + ;;
> + powerpc-*)
>
> but the original wanted:
>
> - ppc64-*linux*|powerpc64-*linux*)
> + powerpc64le-*)
> + LD="${LD-ld} -m elf32lppclinux"
> + ;;
> + powerpc64-*)
>
> But, the originally supplied version confuses me yet again, so I'm not
> committing the fix myself...
>
> How can it be correct to say "-m elf32lppclinux" (32-bit) when $host is
> explicitly 64-bit? That seems like utter garbage to me. What am I
> missing this time?
I don't get it either, and I can't test it. I trust the ppcle community
will commence shouting if the patches have done something horrible. However,
if there is any nonsense here, it predates my recent patch butchering,
because even the pre-patched code seems to mix 32bit and 64bit concepts
liberally.
If someone would like to apply (or send me) a patch that adds a comment
explaining why this code needs to look so odd, that would be very helpful!
Hopefully the repository at least reflects the changes you wanted now in
any case. Sorry for the earlier sloppiness.
Cheers,
--
Gary V. Vaughan (gary AT gnu DOT org)
signature.asc
Description: Message signed with OpenPGP using GPGMail
Re: Two-month patch ping: Re: powerpc*le-linux support
On 2013-08-22 10:20, Gary V. Vaughan wrote:
> Hi Peter,
>
> On Aug 22, 2013, at 2:54 PM, Peter Rosin wrote:
>
>> On 2013-08-22 09:40, Gary V. Vaughan wrote:
Can we please get this simple patch pushed?
>>>
>>> Done.
>>
>> To me, it appears as if what you actually pushed was not what was posted?
>
> I am an idiot. Thanks for the heads up, fixed in the following change set.
Still not right though, sorry.
You ended up doing:
- ppc64-*linux*|powerpc64-*linux*)
+ powerpcle-*)
+ LD="${LD-ld} -m elf32lppclinux"
+ ;;
+ powerpc-*)
but the original wanted:
- ppc64-*linux*|powerpc64-*linux*)
+ powerpc64le-*)
+ LD="${LD-ld} -m elf32lppclinux"
+ ;;
+ powerpc64-*)
But, the originally supplied version confuses me yet again, so I'm not
committing the fix myself...
How can it be correct to say "-m elf32lppclinux" (32-bit) when $host is
explicitly 64-bit? That seems like utter garbage to me. What am I
missing this time?
Cheers,
Peter
Re: powerpc*le-linux support
On 2013-08-22 15:25, Alan Modra wrote: > On Thu, Aug 22, 2013 at 01:16:04PM +0200, Peter Rosin wrote: >> 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? > > Yes, we might need to handle those cases too. I've only just started > looking into the cross-endian multilib support in gcc.. > > As to why the cases I handled are more important: On a powerpc64le > linux host where the compiler defaulted to producing 64-bit objects > (which is how we generally build compilers nowadays) libtool added > -m elf64ppc to $LD here. Being the option for 64-bit big-endian, that > caused complete failure for *native* 64-bit little-endian. Which is > where the action is at the moment. Ah, I see. Thanks! Cheers, Peter
Re: powerpc*le-linux support
On Thu, Aug 22, 2013 at 01:16:04PM +0200, Peter Rosin wrote: > 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? Yes, we might need to handle those cases too. I've only just started looking into the cross-endian multilib support in gcc.. As to why the cases I handled are more important: On a powerpc64le linux host where the compiler defaulted to producing 64-bit objects (which is how we generally build compilers nowadays) libtool added -m elf64ppc to $LD here. Being the option for 64-bit big-endian, that caused complete failure for *native* 64-bit little-endian. Which is where the action is at the moment. -- Alan Modra Australia Development Lab, IBM
Re: powerpc*le-linux support
On 2013-08-22 10:19, Gary V. Vaughan wrote:
> On Aug 22, 2013, at 2:59 PM, Peter Rosin 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
Re: powerpc*le-linux support
Hi Peter, On Aug 22, 2013, at 3:19 PM, "Gary V. Vaughan" wrote: >> All other inner cases match one of the outer or-ed expressions (i.e. >> from the first hunk) quite closely, but the outer match is still >> powerpc*-*linux* while the inner match has dropped the trailing >> -*linux* part. I would have kept them in sync. > > The other branches are inconsistent here too, so either is fine IMHO. Oh, I see what you mean, and I agree. I was fixating on the *linux* suffix. Fixed, thanks. Cheers, -- Gary V. Vaughan (gary AT gnu DOT org) signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Two-month patch ping: Re: powerpc*le-linux support
Hi Peter, On Aug 22, 2013, at 2:54 PM, Peter Rosin wrote: > On 2013-08-22 09:40, Gary V. Vaughan wrote: >>> Can we please get this simple patch pushed? >> >> Done. > > To me, it appears as if what you actually pushed was not what was posted? I am an idiot. Thanks for the heads up, fixed in the following change set. Cheers, -- Gary V. Vaughan (gary AT gnu DOT org) signature.asc Description: Message signed with OpenPGP using GPGMail
Re: powerpc*le-linux support
On Aug 22, 2013, at 2:59 PM, Peter Rosin wrote:
> Hi!
>
> Ok, Gary pushed something while I wrote this, but I'm sending it
> anyway since what he pushed didn't look quite right to me…
Argh. I pasted the patch from my browser to a terminal to save hunting
my archives for the original email, and mangled the hunks during application.
I pushed a fix too, so that the last two commits do match the original
patch.
> On 2013-06-06 07:18, Alan Modra wrote:
>> On Thu, Jun 06, 2013 at 11:31:34AM +0930, Alan Modra wrote:
>>> This adds support for little-endian powerpc linux, and tidies the
>>> existing host match for powerpc. config.sub won't return ppc*-*linux*
>>> so there isn't much point in matching that.
>>
>>> - ppc*-*linux*|powerpc*-*linux*)
>>> + powerpcle*)
>>> + LD="${LD-ld} -m elf64lppc"
>>> + ;;
>>> + powerpc*)
>>> LD="${LD-ld} -m elf64ppc"
>>> ;;
>>
>> I didn't get that quite right. 'powerpc*' in the above matches too
>> much, for example when your host is powerpc64-linux and target
>> powerpc64le-linux you'll get -melf64ppc added to LD. Since
>> powerpc64le-linux-ld wants -melf64lppc (or nothing) that will fail.
>> Revised as follows.
>>
>> * m4/libtool.m4 (ld -m flags): Remove non-canonical ppc host match.
>
> The macro/function you are changing is _LT_ENABLE_LOCK, so that should be
>
> * m4/libtool.m4 (_LT_ENABLE_LOCK): …
Agreed. I should have checked and changed that on commit, my bad.
>> Support little-endian powerpc linux host.
>>
>> 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*)
>
> All other inner cases match one of the outer or-ed expressions (i.e.
> from the first hunk) quite closely, but the outer match is still
> powerpc*-*linux* while the inner match has dropped the trailing
> -*linux* part. I would have kept them in sync.
The other branches are inconsistent here too, so either is fine IMHO.
> 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.
> 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.
>
>> @@ -1347,7 +1350,10 @@ s390*-*linux*|s390*-*tpf*|sparc*-*linux*)
>>x86_64-*linux*)
>> LD="${LD-ld} -m elf_x86_64"
>> ;;
>> - ppc*-*linux*|powerpc*-*linux*)
>> + powerpcle-*)
>> +LD="${LD-ld} -m elf64lppc"
>> +;;
>> + powerpc-*)
>> LD="${LD-ld} -m elf64ppc"
>> ;;
>>s390*-*linux*|s390*-*tpf*)
>>
>>
>
> Or what am I not getting? I'm probably just ignorant...ö
Without access to ppc linux compilers and cross compilers, I only ran
the test suite on my Mac before committing, which doesn't exercise any
of the changes, but is at least a sanity check against syntax errors or
similar breakage.
Alan, your patch is already a step forward in providing the support you
need without breaking anything else, so I'm happy to have committed it
finally. Peter, your point about cross compiling between the 32bit and
64bit APIs is valid too, so I'd be even happier to apply a follow-up that
handles those cases too.
Unfortunately, we still need to figure out a plan to handle the patch
backlog problem that left the original in limbo for so long.
Cheers,
--
Gary V. Vaughan (gary AT gnu DOT org)
signature.asc
Description: M
Re: powerpc*le-linux support
Hi!
Ok, Gary pushed something while I wrote this, but I'm sending it
anyway since what he pushed didn't look quite right to me...
On 2013-06-06 07:18, Alan Modra wrote:
> On Thu, Jun 06, 2013 at 11:31:34AM +0930, Alan Modra wrote:
>> This adds support for little-endian powerpc linux, and tidies the
>> existing host match for powerpc. config.sub won't return ppc*-*linux*
>> so there isn't much point in matching that.
>
>> - ppc*-*linux*|powerpc*-*linux*)
>> + powerpcle*)
>> +LD="${LD-ld} -m elf64lppc"
>> +;;
>> + powerpc*)
>> LD="${LD-ld} -m elf64ppc"
>> ;;
>
> I didn't get that quite right. 'powerpc*' in the above matches too
> much, for example when your host is powerpc64-linux and target
> powerpc64le-linux you'll get -melf64ppc added to LD. Since
> powerpc64le-linux-ld wants -melf64lppc (or nothing) that will fail.
> Revised as follows.
>
> * m4/libtool.m4 (ld -m flags): Remove non-canonical ppc host match.
The macro/function you are changing is _LT_ENABLE_LOCK, so that should be
* m4/libtool.m4 (_LT_ENABLE_LOCK): ...
> Support little-endian powerpc linux host.
>
> 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*)
All other inner cases match one of the outer or-ed expressions (i.e.
from the first hunk) quite closely, but the outer match is still
powerpc*-*linux* while the inner match has dropped the trailing
-*linux* part. I would have kept them in sync. 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?
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.
> @@ -1347,7 +1350,10 @@ s390*-*linux*|s390*-*tpf*|sparc*-*linux*)
> x86_64-*linux*)
> LD="${LD-ld} -m elf_x86_64"
> ;;
> - ppc*-*linux*|powerpc*-*linux*)
> + powerpcle-*)
> + LD="${LD-ld} -m elf64lppc"
> + ;;
> + powerpc-*)
> LD="${LD-ld} -m elf64ppc"
> ;;
> s390*-*linux*|s390*-*tpf*)
>
>
Or what am I not getting? I'm probably just ignorant...ö
Cheers,
Peter
Re: Two-month patch ping: Re: powerpc*le-linux support
On 2013-08-22 09:40, Gary V. Vaughan wrote: >> Can we please get this simple patch pushed? > > Done. To me, it appears as if what you actually pushed was not what was posted? Cheers, Peter
Re: Two-month patch ping: Re: powerpc*le-linux support
Hi Brooks, Alan, On Aug 22, 2013, at 12:59 AM, Brooks Moses wrote: > Ping? > > (And adding libtool@, in hopes of getting a little more attention, as pings > on libtool-patches@ seem to be going nowhere.) > > On 06/05/2013 07:01 PM, Alan Modra wrote: >> This adds support for little-endian powerpc linux, and tidies the >> existing host match for powerpc. config.sub won't return ppc*-*linux* >> so there isn't much point in matching that. >> >> * m4/libtool.m4 (ld -m flags): Remove non-canonical ppc host match. >> Support little-endian powerpc linux host. > > (http://lists.gnu.org/archive/html/libtool-patches/2013-06/msg1.html) > > It's been two and a half months since this patch was posted, without any > review or response. My sincere apologies. Sadly, your patch is among a backlog of unapplied patches that are growing faster than I can keep up alongside my current workload :( > Can we please get this simple patch pushed? Done. > I understand maintainers becoming busy and/or moving on to other things and > being unable to keep up -- I've been there, too. What can we do to help? Thank you immensely for your extreme patience. The problem has become triaging the unapplied patches from the mailing-list. My involvement with libtool has almost always been new features and release management, and extremely sporadic (I work on libtool a lot in bursts of a month or two here and there, between long gaps of several months) - which has been fine until recently, because there have always been sufficient maintainers to keep up with the backlog. That is obviously no longer the case :( Would you, or anyone else you know be interested in helping with the somewhat dull, but very important process of applying patches that obviously move libtool forward, asking for revisions to patches that could be useful but are obviously lacking in some way, and flagging the rest for further review by me (in the remaining non- obvious cases)? That would help immensely in getting libtool over the current state of stagnation… Cheers, -- Gary V. Vaughan (gary AT gnu DOT org) signature.asc Description: Message signed with OpenPGP using GPGMail
Re: powerpc*le-linux support
On Thu, Jul 18, 2013 at 08:31:03AM +0930, Alan Modra wrote: > Ping? > http://lists.gnu.org/archive/html/libtool-patches/2013-06/msg1.html > > On Thu, Jun 06, 2013 at 02:48:22PM +0930, Alan Modra wrote: > > * m4/libtool.m4 (ld -m flags): Remove non-canonical ppc host match. > > Support little-endian powerpc linux host. This simple patch has now been waiting for review for over 2 months! Did I miss seeing the funeral announcement for the libtool project? -- Alan Modra Australia Development Lab, IBM
Re: powerpc*le-linux support
> Haven't found enough time to do the review .. but I should have to try to find at least a second. I see patch is relevant to libtool, sorry for my previous pointless comment.
Re: powerpc*le-linux support
> [...] config.sub won't return ppc*-*linux* so there isn't much point in
> matching that. [...]
Haven't found enough time to do the review but issues with
config.{guess,sub} should be discussed on different list:
config-patc...@gnu.org
Pavel
Re: powerpc*le-linux support
Ping? http://lists.gnu.org/archive/html/libtool-patches/2013-06/msg1.html On Thu, Jun 06, 2013 at 02:48:22PM +0930, Alan Modra wrote: > * m4/libtool.m4 (ld -m flags): Remove non-canonical ppc host match. > Support little-endian powerpc linux host. -- Alan Modra Australia Development Lab, IBM
powerpc*le-linux support
This adds support for little-endian powerpc linux, and tidies the
existing host match for powerpc. config.sub won't return ppc*-*linux*
so there isn't much point in matching that.
* m4/libtool.m4 (ld -m flags): Remove non-canonical ppc host match.
Support little-endian powerpc linux host.
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*)
@@ -1347,7 +1350,10 @@ s390*-*linux*|s390*-*tpf*|sparc*-*linux*)
x86_64-*linux*)
LD="${LD-ld} -m elf_x86_64"
;;
- ppc*-*linux*|powerpc*-*linux*)
+ powerpcle*)
+ LD="${LD-ld} -m elf64lppc"
+ ;;
+ powerpc*)
LD="${LD-ld} -m elf64ppc"
;;
s390*-*linux*|s390*-*tpf*)
--
Alan Modra
Australia Development Lab, IBM
Re: powerpc*le-linux support
On Thu, Jun 06, 2013 at 11:31:34AM +0930, Alan Modra wrote:
> This adds support for little-endian powerpc linux, and tidies the
> existing host match for powerpc. config.sub won't return ppc*-*linux*
> so there isn't much point in matching that.
> - ppc*-*linux*|powerpc*-*linux*)
> + powerpcle*)
> + LD="${LD-ld} -m elf64lppc"
> + ;;
> + powerpc*)
> LD="${LD-ld} -m elf64ppc"
> ;;
I didn't get that quite right. 'powerpc*' in the above matches too
much, for example when your host is powerpc64-linux and target
powerpc64le-linux you'll get -melf64ppc added to LD. Since
powerpc64le-linux-ld wants -melf64lppc (or nothing) that will fail.
Revised as follows.
* m4/libtool.m4 (ld -m flags): Remove non-canonical ppc host match.
Support little-endian powerpc linux host.
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*)
@@ -1347,7 +1350,10 @@ s390*-*linux*|s390*-*tpf*|sparc*-*linux*)
x86_64-*linux*)
LD="${LD-ld} -m elf_x86_64"
;;
- ppc*-*linux*|powerpc*-*linux*)
+ powerpcle-*)
+ LD="${LD-ld} -m elf64lppc"
+ ;;
+ powerpc-*)
LD="${LD-ld} -m elf64ppc"
;;
s390*-*linux*|s390*-*tpf*)
--
Alan Modra
Australia Development Lab, IBM
