Syslinux - Sep 2016 - linking external library into module

Thank you, that clears everything up.
> -------- Original Message --------
> Subject: RE: [syslinux] linking external library into module
> From: "H. Peter Anvin" <hpa at zytor.com>
> Date: Thu, September 29, 2016 2:55 pm
> To: jeff.williams at pideso.com, syslinux at zytor.com
> 
> 
> 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.
> >> 
> >> 
> >> 	-hpa
> 
> Yes, the ld command line is generally processed in order.
> -- 
> Sent from my Android device with K-9 Mail. Please excuse brevity and
formatting.