Fix make 3.81 build errors

  Make rules in make 3.81 are parsed slightly different than newer
versions of make.

Patch b5884fa7101cc528f07fd57c3de445a3680964a6 caused build errors
on the older 3.81:
make[4]: *** No rule to make target `../../../binutils-gdb/gdb/gdbserver/common/btrace-common.c'.  Stop.

This is because make 3.81 was using the wrong rule to build btrace-common.c,
causing it to look in the wrong source directory.

This fix simply re-orders the make rules in gdbserver. However, for reasons
I am unsure of, this requires moving the corresponding ipa rule. I've tried
many many different combinations, and this is the only one that works.
Therefore, not pushing as obvious and asking for review first.

Tested on x86 and Ubuntu-AArch32-native-extended-gdbserver-m32 builds using
both make 4.1 and make 3.81

gdbserver/

2018-02-19  Alan Hayward  <alan.hayward@arm.com>

	* Makefile.in: Switch order of make rules. 

---
 gdb/gdbserver/Makefile.in | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)
  

On Feb 19 2018, Alan Hayward <Alan.Hayward@arm.com> wrote:

> Make rules in make 3.81 are parsed slightly different than newer
> versions of make.

Probably this change:

* WARNING: Backward-incompatibility!
  The pattern-specific variables and pattern rules are now applied in the
  shortest stem first order instead of the definition order (variables
  and rules with the same stem length are still applied in the definition
  order). This produces the usually-desired behavior where more specific
  patterns are preferred. To detect this feature search for 'shortest-stem'
  in the .FEATURES special variable.

Andreas.
  

> On 19 Feb 2018, at 16:11, Andreas Schwab <schwab@suse.de> wrote:

> 

> On Feb 19 2018, Alan Hayward <Alan.Hayward@arm.com> wrote:

> 

>> Make rules in make 3.81 are parsed slightly different than newer

>> versions of make.

> 

> Probably this change:

> 

> * WARNING: Backward-incompatibility!

>  The pattern-specific variables and pattern rules are now applied in the

>  shortest stem first order instead of the definition order (variables

>  and rules with the same stem length are still applied in the definition

>  order). This produces the usually-desired behavior where more specific

>  patterns are preferred. To detect this feature search for 'shortest-stem'

>  in the .FEATURES special variable.

> 


Make sense. But I’m still confused as to exactly why the IPA rules are
getting hit.
Thanks for the explanation.


> On 19 Feb 2018, at 16:16, Simon Marchi <simark@simark.ca> wrote:

> 

> Hi Alan,

> 

> I hit this problem with GNU Make 3.81 before, there's a comment in the gdbserver Makefile:

> 

> # Note: Between two matching pattern rules, GNU Make 3.81 chooses the first one.

> # Therefore, this one needs to be before "%.o: %.c" for it to be considered for

> # files such as linux-amd64-ipa.o generated from linux-amd64-ipa.c.

> #

> # Later versions of GNU Make choose the rule with the shortest stem, so it would

> # work in any order.

> 

> So to please Make 3.81, you need to order rules from the more specific (shorter stem)

> to the more general (longer stem) if you want it to pick up the more specific rule.

> That means putting "common/%.o: ../common/%.c" before "%.o: %.c".

> 

> I think there's a way to do it while keeping related rules a bit more together.  What

> about the patch below?  I moved a bit more than necessary (e.g. the arch/ rule) to put

> all rules for things that go into the gdbserver binary together and have a similar order

> for both gdbserver and the IPA.

> 


Thanks for the patch.
I’m happy with this. It’s makes the makefile tidier than with my fix.
I’ve tested it on my builds and it works fine for me (make 3.81, make 4) x (x86, aarch32).
I would have made my patch look a little neater, but I really didn’t want to touch more than I had to.

Alan.
  

On 2018-02-19 11:39, Alan Hayward wrote:
> Thanks for the patch.
> I’m happy with this. It’s makes the makefile tidier than with my fix.
> I’ve tested it on my builds and it works fine for me (make 3.81, make
> 4) x (x86, aarch32).
> I would have made my patch look a little neater, but I really didn’t
> want to touch more than I had to.
> 
> Alan.

Thanks for testing.  Can you take care of pushing it?

Simon
  

On 19/02/18 16:39, Alan Hayward wrote:
>> On 19 Feb 2018, at 16:16, Simon Marchi <simark@simark.ca> wrote:
> Thanks for the patch.
> I’m happy with this. It’s makes the makefile tidier than with my fix.
> I’ve tested it on my builds and it works fine for me (make 3.81, make 4) x (x86, aarch32).
> I would have made my patch look a little neater, but I really didn’t want to touch more than I had to.

can you please commit one of the fixes or revert the breaking change..

our toolchain builds are broken because of this.
  

> On 19 Feb 2018, at 16:44, Simon Marchi <simark@simark.ca> wrote:

> 

> On 2018-02-19 11:39, Alan Hayward wrote:

>> Thanks for the patch.

>> I’m happy with this. It’s makes the makefile tidier than with my fix.

>> I’ve tested it on my builds and it works fine for me (make 3.81, make

>> 4) x (x86, aarch32).

>> I would have made my patch look a little neater, but I really didn’t

>> want to touch more than I had to.

>> Alan.

> 

> Thanks for testing.  Can you take care of pushing it?

> 

> Simon


Pushed as requested.


Thanks,
Alan.