[syslinux] linking external library into module

[H. Peter Anvin]

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.