[Bug dynamic-link/20019] Program received signal SIGSEGV, Segmentation fault

["carlos at redhat dot com" <sourceware-bugzilla at sourceware dot org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=20019

--- Comment #6 from Carlos O'Donell <carlos at redhat dot com> ---
(In reply to Florian Weimer from comment #5)
> Yes, the symbol version is missing:
> 
> $ eu-readelf -s libbar.so  | grep memmove
>     2: 0000000000000000      0 NOTYPE  GLOBAL DEFAULT    UNDEF memmove
> 
> The static linker invocation is incorrect.  If you link in libc.so.6, the
> problem goes away, “-z now” or no “-z now”.
> 
> Considering that the lack of symbol versions makes these objects very much
> undefined anyway, is there anything here we need to fix in glibc ld.so?

Yes, there is, why didn't the relocation dependency cause libc.so.6 to be
initialized first? The dynamic linker has support for relocation dependency
sorting, is it incomplete? We should fix this.

I also don't think the static linker has enough information to correctly
diagnose this. There is nothing wrong with building a shared object that has an
undefined reference to a symbol. You just accept that such an undefined
reference will bind to the default version of the symbol in the first located
object, just like a dlopen/dlsym would.

I think this _should_ be made to work by sorting libc.so.6's initialization
ahead of libbar.so because of the relocation dependency.

Thoughts?

-- 
You are receiving this mail because:
You are on the CC list for the bug.