[Bug ld/31216] On aarch64 several sections are unnecessarily mapped to segment with executable rights
https://sourceware.org/bugzilla/show_bug.cgi?id=31216 --- Comment #3 from Marcin Godlewski --- Or is it GNU ld build time configuration parameter and the issue should be addressed to debian/ubuntu GNU ld maintainers? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/31216] On aarch64 several sections are unnecessarily mapped to segment with executable rights
https://sourceware.org/bugzilla/show_bug.cgi?id=31216 Nick Clifton changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |NOTABUG CC||nickc at redhat dot com --- Comment #4 from Nick Clifton --- (In reply to Marcin Godlewski from comment #2 and #3) > Does it mean -zseparate-code is enabled by default in x86-64, but not in > aarch64? > Or is it GNU ld build time configuration parameter and the issue should be > addressed to debian/ubuntu GNU ld maintainers? Both. There is a configure time option (--enable-separate-code=[yes|no]) which can be used to control the linker's default behaviour. In addition, if that configure option is not used then it is still enabled by default for x86_64 targets, but no others. (See the end of ld/configure.tgt). -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/31047] relocation R_X86_64_NONE against absolute symbol `__dtrace_test_prov___place' in section `.text.startup' is disallowed
https://sourceware.org/bugzilla/show_bug.cgi?id=31047 H.J. Lu changed: What|Removed |Added Last reconfirmed||2024-01-08 Status|UNCONFIRMED |WAITING Ever confirmed|0 |1 --- Comment #1 from H.J. Lu --- Is it possible to create a testcase? A binary object is OK. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/31047] relocation R_X86_64_NONE against absolute symbol `__dtrace_test_prov___place' in section `.text.startup' is disallowed
https://sourceware.org/bugzilla/show_bug.cgi?id=31047 --- Comment #2 from H.J. Lu --- (In reply to H.J. Lu from comment #1) > Is it possible to create a testcase? A binary object is OK. If R_386_NONE is also impacted, please also provide such a testcase. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/31216] On aarch64 several sections are unnecessarily mapped to segment with executable rights
https://sourceware.org/bugzilla/show_bug.cgi?id=31216 --- Comment #5 from Marcin Godlewski --- Clear, thank you for the explanation. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/31208] strip with no arguments sometimes breaks ELF alignment requirements
https://sourceware.org/bugzilla/show_bug.cgi?id=31208 --- Comment #4 from Matt Wozniski --- > So how did that load segment get there? I strongly suspect that it's the result of the ELF editing performed by `auditwheel repair`, from https://github.com/pypa/auditwheel - though I haven't dug in to confirm that for certain. The error message that you get if you try to dlopen() the shared library after having called `strip` on it is: ELF load command address/offset not properly aligned There's a lot of reports of that error message on Google for Python packages that were packaged by `auditwheel repair`: https://github.com/linuxdeploy/linuxdeploy/issues/204 https://github.com/marcelotduarte/cx_Freeze/issues/1048 https://github.com/scipy/scipy/issues/17438 etc, which certainly seems to point a finger in the direction of the common Python packaging tools. Idiomatic pre-compiled Python libraries vendor their shared library dependencies, and `auditwheel repair` is the tooling used to do so (including renaming the vendored shared libraries to avoid version collisions between Python packages, and editing the shared libraries themselves to update the SONAME and DT_NEEDED to match the renamed libraries). -- You are receiving this mail because: You are on the CC list for the bug.
