Undefined symbol

Carlo Kok ck@remobjects.com
Mon Feb 13 19:22:00 GMT 2017

On 2017-02-13 19:52, Florian Weimer wrote:
> On 02/13/2017 02:31 PM, Carlo Kok wrote:
>> The call it fails at is _start, specifically:
>> callq  __libc_start_main@PLT
>> from gdb it looks like:
>> 0x000000000026a9b4 <+36>:    callq  0x26e860
>> <pthread_mutex_timedlock@plt+16>
>> Goes here:
>> => 0x000000000026e860 <+16>:    jmpq   *0xd72(%rip)        # 0x26f5d8
>> Goes to 0x0000000 (LD_BIND_NOW=1)
> That's probably an unrelated issue caused by LD_BIND_NOW, so it's not
> worth debugging that.
>> Without LD_BIND_NOW=1 the jmpq jumps over itself and calls what seems to
>> be symbol loading code, fails with an error, either way it never seems
>> to go into libc_start_main.
> Sorry, I don't know how to debug this further without access to the
> binaries and single-stepping through the dynamic linker.
> Florian


Wasn't sure that the policy was on sending executables here so I didn't 
originally. It's pretty much a test of my compiler to dynamic library 
support. (None of the code gets called at this point since it fails 
before entering libc_start_main)


Carlo Kok
RemObjects Software

More information about the Libc-help mailing list