This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

--- 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  | grep memmove
>     2: 0000000000000000      0 NOTYPE  GLOBAL DEFAULT    UNDEF memmove
> The static linker invocation is incorrect.  If you link in, 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

Yes, there is, why didn't the relocation dependency cause 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's initialization
ahead of because of the relocation dependency.


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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]