On 30 Apr 2012, Darrell Anderson spake thusly:

>> Stripping away some of my redundant geekberish, the rule is
>> simple enough:
>
> Oh my, that was a lot of info. I'll need to save and keep as a reference!

Windows PE's path searching and symbol resolution rules are much too
simplistic. ELF's are, I think all agree, much too complicated. :)

>> > The peculiar thing about this problem is only kword and kpresenter are
>> > affected. Possibly there are other "undefined symbol" problems in my
>> > builds that I have not yet noticed, but I'm guessing kword and
>> > kpresenter are not linking correctly during my builds. I don't know
>> > how to debug further or what to look for.
>> 
>> You might find the linker flag --no-undefined (-Wl,--no-undefined in
>> LDFLAGS) to be useful. (I thought Trinity was passing it already, but I
>> could be wrong.)
>
> The build log is filled with --no-undefined. I presume the flag is
> used when building kword and kpresenter too, although I did not try to
> filter the log that deep.

Oh. Well, if --no-undefined is used, it should be impossible to have
undefined symbols after you've finished linking. If you have them, it is
probable that the shared libraries you are running against (as shown via
ldd) are not the same as the ones you linked against. If you extract the
link line for one of the failing programs and rerun it from the same
directory wihout --silent, you'll get a gcc command: re-execute that
with -Wl,--verbose attached, and you'll see what libraries are being
picked up, and from where.

>> Other more-or-less-obscure things you might find useful in this hunt:
>> 
>>  - dynamic linker symbol debugging, set LD_DEBUG=symbols before running
>>    the program: very verbose: see also LD_DEBUG=help (then run any
>>    dynamically-linked program at all, e.g. LD_DEBUG=help ls)
>
> Yesterday I toyed a bit with the LD_DEBUG variable. LD_DEBUG=symbols
> took so long that I gave up and interrrupted the output. I have no
> idea what to look for in that output.

The symbol whose resolution is failing :) but it's likely it won't
appear there at all, except as an undefined symbol being searched for.
It is true that running it on a KDE program is likely to be suicidal, it
produces insane amounts of output even when you run it on ls(1) :)

>>  - linker symbol tracing, -Wl,--trace-symbol=SYMBOL in LDFLAGS,
>>    which prints every file the named symbol appears in
>
> I'm not following with that one. Exactly what do I do?

As above, run the link command for the failing program by hand without
--silent to get the GCC command used to link, then re-execute that
with -Wl,--trace-symbol=FOO (where FOO is the symbol reported as being
undefined). That'll tell you what library it was found in at link time.
I bet you'll find that you've got two copies of that library on your
system somehow, and the library ldd tells you it's picking up when you
run ldd on the failing binary is the other one... or that at least it's
not got the same contents as the one that the --trace-symbol reports
that the symbol is found in.

-- 
NULL && (void)