jeff.williams at pideso.com
2016-Sep-29 14:16 UTC
[syslinux] linking external library into module
Thank you for the confirmation about the ABI issue. I'm a bit puzzled by your answer for my #2, below. I could easily be missing something, but I was under the impression that what I had changed was the position of the command line flags to ld, not the relative position and ordering of the linked libraries. Am I misunderstanding what is stored in $(LDFLAGS)? I mean, I'm not ending up with unresolved symbols (the usual issue with library ordering); both command lines build a seemingly valid binary output. It's just that the first positioning of $(LDFLAGS) results in a binary that executes as written while the second positioning of $(LDFLAGS) yields a binary that fails - and fails differently depending upon seemingly unrelated source code additions. For example, using the second positioning of $(LDFLAGS) I might get three lines of printed output from three consecutive printf() statements, but adding a fourth consecutive printf() statement and recompiling will yield output from only the first printf(), not the second, third, or fourth. Move the $(LDFLAGS) in the ld command so they preceed the -o option and the generated binary works correctly in both cases. It's almost like ld is performing in-order processing of its command line flags. To put is more clearly, it's like ld is applying behaviorial command line flags to the objects that follow the flags, but not to objects that precede the flags. Of course, this could easily be down to my not understanding the correct processing of ld's command line (I usually just use gcc/g++ to generate the link magic for ld). Maybe it's expected that different behaviorial flags will apply to different object files supplied on the linker command line. If you could clarify your answer, it would be appreciated.> -------- Original Message -------- > Subject: Re: [syslinux] linking external library into module > From: "H. Peter Anvin" <hpa at zytor.com> > Date: Thu, September 29, 2016 12:08 am > To: jeff.williams at pideso.com, syslinux at zytor.com > > > On 09/22/16 07:26, Jeff Williams via Syslinux wrote: > ]\> > > 1) It appears that external libraries will not link correctly into a > > com32 module if they weren't built with the same flags as are used in > > the syslinux com32 module build. There is no error output during the > > link, you just end up with seemingly random run-time issues. This may > > partially depend upon #2, below. > > > > This is very true. The Syslinux ABI is not compatible with any other ABI. > > > 2) The final link command line order is surprisingly fussy. "$(LD) > > $(LDFLAGS) -o $@ $^ $(C_LIBS)" builds a com32 module that runs pretty > > reliably. "$(LD) -o $@ $^ $(LDFLAGS) $(C_LIBS)" builds a com32 module > > that may or may not run depending upon how much and in what order your > > .c source code may be. Order of flags on the tool's command line > > matters? Looks like it. Weird. > > When it comes to archives (.a), the order on the command line does > indeed matter; they are normally required to be such that dependencies > are resolved to the right. The GNU ld specific options --start-group > and --end-group can be used to change that behavior. > > > -hpa
On September 29, 2016 7:16:19 AM PDT, jeff.williams at pideso.com wrote:>Thank you for the confirmation about the ABI issue. > >I'm a bit puzzled by your answer for my #2, below. I could easily be >missing something, but I was under the impression that what I had >changed was the position of the command line flags to ld, not the >relative position and ordering of the linked libraries. Am I >misunderstanding what is stored in $(LDFLAGS)? > >I mean, I'm not ending up with unresolved symbols (the usual issue with >library ordering); both command lines build a seemingly valid binary >output. It's just that the first positioning of $(LDFLAGS) results in a >binary that executes as written while the second positioning of >$(LDFLAGS) yields a binary that fails - and fails differently depending >upon seemingly unrelated source code additions. > >For example, using the second positioning of $(LDFLAGS) I might get >three lines of printed output from three consecutive printf() >statements, but adding a fourth consecutive printf() statement and >recompiling will yield output from only the first printf(), not the >second, third, or fourth. Move the $(LDFLAGS) in the ld command so they >preceed the -o option and the generated binary works correctly in both >cases. > >It's almost like ld is performing in-order processing of its command >line flags. To put is more clearly, it's like ld is applying >behaviorial >command line flags to the objects that follow the flags, but not to >objects that precede the flags. > >Of course, this could easily be down to my not understanding the >correct >processing of ld's command line (I usually just use gcc/g++ to generate >the link magic for ld). Maybe it's expected that different behaviorial >flags will apply to different object files supplied on the linker >command line. > >If you could clarify your answer, it would be appreciated. > >> -------- Original Message -------- >> Subject: Re: [syslinux] linking external library into module >> From: "H. Peter Anvin" <hpa at zytor.com> >> Date: Thu, September 29, 2016 12:08 am >> To: jeff.williams at pideso.com, syslinux at zytor.com >> >> >> On 09/22/16 07:26, Jeff Williams via Syslinux wrote: >> ]\> >> > 1) It appears that external libraries will not link correctly into >a >> > com32 module if they weren't built with the same flags as are used >in >> > the syslinux com32 module build. There is no error output during >the >> > link, you just end up with seemingly random run-time issues. This >may >> > partially depend upon #2, below. >> > >> >> This is very true. The Syslinux ABI is not compatible with any other >ABI. >> >> > 2) The final link command line order is surprisingly fussy. "$(LD) >> > $(LDFLAGS) -o $@ $^ $(C_LIBS)" builds a com32 module that runs >pretty >> > reliably. "$(LD) -o $@ $^ $(LDFLAGS) $(C_LIBS)" builds a com32 >module >> > that may or may not run depending upon how much and in what order >your >> > .c source code may be. Order of flags on the tool's command line >> > matters? Looks like it. Weird. >> >> When it comes to archives (.a), the order on the command line does >> indeed matter; they are normally required to be such that >dependencies >> are resolved to the right. The GNU ld specific options --start-group >> and --end-group can be used to change that behavior. >> >> >> -hpaYes, the ld command line is generally processed in order. -- Sent from my Android device with K-9 Mail. Please excuse brevity and formatting.