patch, 3 partsMakefile: Reorder linker flags in the git executable rule

> file arguments, for example when linking git while building with
> "gmake LDFLAGS=-L$prefix/lib".  This moves the ALL_LDFLAGS variable
> expansion in the git executable rule to be consistent with all the
> other linking rules.
>
> Signed-off-by: David Michael <fedora.dm0@gmail.com>
> ---
>  Makefile | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/Makefile b/Makefile
> index fcd51ac..827006b 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -1610,8 +1610,8 @@ git.sp git.s git.o: EXTRA_CPPFLAGS = \
>         '-DGIT_INFO_PATH="$(infodir_relative_SQ)"'
>
>  git$X: git.o GIT-LDFLAGS $(BUILTIN_OBJS) $(GITLIBS)
> -       $(QUIET_LINK)$(CC) $(ALL_CFLAGS) -o $@ git.o \
> -               $(BUILTIN_OBJS) $(ALL_LDFLAGS) $(LIBS)
> +       $(QUIET_LINK)$(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) git.o \
> +               $(BUILTIN_OBJS) $(LIBS)
>
>  help.sp help.s help.o: common-cmds.h
>
> --
> 1.9.3

> On Sun, Oct 26, 2014 at 1:33 PM, David Michael <fedora.dm0@gmail.com> wrote:
> > The XL C compiler can fail due to mixing library path and object
> 
> Can you explain in the commit message the actual nature of the failure
> so that readers can understand more precisely how this change helps?

> On Sun, Oct 26, 2014 at 01:45:10PM -0400, Eric Sunshine wrote:
>
>> On Sun, Oct 26, 2014 at 1:33 PM, David Michael <fedora.dm0@gmail.com> wrote:
>> > The XL C compiler can fail due to mixing library path and object
>>
>> Can you explain in the commit message the actual nature of the failure
>> so that readers can understand more precisely how this change helps?
>
> Based on past experience, it is probably "the compiler complains and
> refuses to run" (or optionally "the compiler silently ignores your
> LDFLAGS" depending on how irritating it wants to be). But it would not
> hurt to be specific.

> On Sun, Oct 26, 2014 at 02:54:56PM -0400, David Michael wrote:
>
>> Yes, the compiler refuses to run by default when a "-L" option occurs
>> after a source/object file.  It tries to interpret it as another file
>> name and fails.
>
> Yeah, I think I have seen similar behavior before, but it has been long
> enough that I no longer remember the compiler in use.
>
>> I believe I can work around the error with an "export _C89_CCMODE=1",
>> but I thought I'd send the patch since this is the only occurrence of
>> the problem, and the argument order is inconsistent with other linker
>> commands in the file.
>
> I don't think working around it makes sense. That would fix your case,
> but nobody else's (though given how long it has been that way without
> complaints, I suspect any other compilers this picky may have died off).

>> Do you want me to resend the patch and reference the IBM documentation
>> in the message?
>
> I don't think you need to. More interesting than documentation is the
> real-world breakage you experienced and the analysis of the situation.
> I'd be fine taking the patch as-is, or if changing anything, mentioning
> the failure mode in the commit message.
>
> -Peff

> >> I believe I can work around the error with an "export _C89_CCMODE=1",
> >> but I thought I'd send the patch since this is the only occurrence of
> >> the problem, and the argument order is inconsistent with other linker
> >> commands in the file.
> >
> > I don't think working around it makes sense. That would fix your case,
> > but nobody else's (though given how long it has been that way without
> > complaints, I suspect any other compilers this picky may have died off).
> 
> I think you meant s/nobody else's/breaks &/;