https://sourceware.org/bugzilla/show_bug.cgi?id=29655
--- Comment #6 from Andreas Krebbel <krebbel at linux dot ibm.com> --- (In reply to Rui Ueyama from comment #5) > Ooh, that's why I did see this only on SuSE's builder. I'm glad that that's > already been handled. I would just like to mention that adding the @PLT isn't really a bugfix. We did this to make life easier with hotpatching. Omitting the @PLT for a non-PIC build is also correct I think. At that point it isn't clear whether the jump needs to go through PLT or not. It could very well be resolved locally. So I think it is anyway up to ld to decide whether a PLT stub is needed or not. > mold does not create PLT for R_390_PC32DBL; it does only for R_390_PLT* > relocs. We can change that so that mold would create a PLT for a PC32 reloc > just like GNU ld does, but that would break Qt. So I'll keep the mold's > current behavior as-is. Could you please elaborate what is so special about Qt here. If a function symbol with a PC32DBL reloc could not be resolved locally adding a PLT stub should be the right thing. -- You are receiving this mail because: You are on the CC list for the bug.
