# [PATCH 2/3] Makefile: Reorder linker flags in the git executable rule 7 messages from 2014-10-26 to 2014-10-28. Participants: David Michael, Eric Sunshine, Jeff King, Junio C Hamano. Thread: https://gitlist.dev/t/37814 ## David Michael, 2014-10-26 17:33 Subject: [PATCH 2/3] Makefile: Reorder linker flags in the git executable rule Message-ID: <87mw8iag72.fsf@gmail.com> URL: https://gitlist.dev/e/87mw8iag72.fsf%40gmail.com ``` The XL C compiler can fail due to mixing library path and object 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 --- 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 ``` ## Eric Sunshine, 2014-10-26 17:45 Subject: Re: [PATCH 2/3] Makefile: Reorder linker flags in the git executable rule Message-ID: URL: https://gitlist.dev/e/CAPig%2BcRUxXw4b2z1Gu4p6GKjnYrt_70h3kbR%2BjzbMP_jY24Sjg%40mail.gmail.com In-Reply-To: <87mw8iag72.fsf@gmail.com> ``` On Sun, Oct 26, 2014 at 1:33 PM, David Michael 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? > 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 > --- > 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 ``` ## Jeff King, 2014-10-26 18:35 Subject: Re: [PATCH 2/3] Makefile: Reorder linker flags in the git executable rule Message-ID: <20141026183530.GA18144@peff.net> URL: https://gitlist.dev/e/20141026183530.GA18144%40peff.net In-Reply-To: ``` On Sun, Oct 26, 2014 at 01:45:10PM -0400, Eric Sunshine wrote: > On Sun, Oct 26, 2014 at 1:33 PM, David Michael 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. Either way, the patch looks good; the whole point of LDFLAGS versus LIBS is to make this distinction in command-line positioning. -Peff ``` ## David Michael, 2014-10-26 18:54 Subject: Re: [PATCH 2/3] Makefile: Reorder linker flags in the git executable rule Message-ID: URL: https://gitlist.dev/e/CAEvUa7nMYn1EJhrX%2BYo-T53-tqB80p_ym9i%2BUa6PMLqZrAFmQw%40mail.gmail.com In-Reply-To: <20141026183530.GA18144@peff.net> ``` On Sun, Oct 26, 2014 at 2:35 PM, Jeff King wrote: > On Sun, Oct 26, 2014 at 01:45:10PM -0400, Eric Sunshine wrote: > >> On Sun, Oct 26, 2014 at 1:33 PM, David Michael 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. 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. 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. IBM documentation has this to say on the noted environment variable: "The default behavior of the c89/cc/c++ command is to expect all options to precede all operands. Setting this variable allows compatibility with historical implementations (other cc commands). When set to 1, the c89/cc/c++ command operates as follows: Options and operands can be interspersed. [...]" Do you want me to resend the patch and reference the IBM documentation in the message? Thanks. David ``` ## Jeff King, 2014-10-27 05:17 Subject: Re: [PATCH 2/3] Makefile: Reorder linker flags in the git executable rule Message-ID: <20141027051705.GC2996@peff.net> URL: https://gitlist.dev/e/20141027051705.GC2996%40peff.net In-Reply-To: ``` 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 ``` ## Junio C Hamano, 2014-10-27 17:42 Subject: Re: [PATCH 2/3] Makefile: Reorder linker flags in the git executable rule Message-ID: URL: https://gitlist.dev/e/xmqq61f5flz6.fsf%40gitster.dls.corp.google.com In-Reply-To: <20141027051705.GC2996@peff.net> ``` Jeff King writes: > 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). I think you meant s/nobody else's/breaks &/; With that, I agree with your assessment. The diff itself is probably fine as-is (I didn't look at it for more than 10 seconds, though ;-). And I agree that it needs to be better explained. >> 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 ``` ## Jeff King, 2014-10-28 22:12 Subject: Re: [PATCH 2/3] Makefile: Reorder linker flags in the git executable rule Message-ID: <20141028221223.GA20722@peff.net> URL: https://gitlist.dev/e/20141028221223.GA20722%40peff.net In-Reply-To: ``` On Mon, Oct 27, 2014 at 10:42:21AM -0700, Junio C Hamano wrote: > >> 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 &/; I meant "using the _C_89_CCMODE workaround does not help anybody else, because their compiler will not support it; instead we should fix the Makefile as David originally proposed". I think we are still agreeing, though. :) -Peff ```