[Bug ld/32675] Wine binaries built with binutils 2.44 no longer run
https://sourceware.org/bugzilla/show_bug.cgi?id=32675 --- Comment #18 from Jeremy Drake --- (In reply to Jeremy Drake from comment #16) > I've been working on this more, including compatibility with the > IMAGE_GUARD_DELAYLOAD_IAT_IN_ITS_OWN_SECTION flag. I just looked at the > https://gitlab.winehq.org/wine/wine/-/merge_requests/7328 and that looks > similar to what I'm trying to do in dlltool. What's different is that $5 > needs to end up in its own .didat section in the output, instead of .data. > > I kind of got the impression that section names were limited to 8 > characters. If that's not true, I could use better section names like in > that merge request. I tried this, and due to the wildcard `.rdata$*` matching `.rdata$didatN`, I had to put the block of delayimp stuff at the beginning of .rdata, or else the entries were not properly sorted and broke things. I think in my patch I will stick with `.didat$N` for the object file section names. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gprof/32779] tst-gmon-gprof-l.sh failure when -g isn't used
https://sourceware.org/bugzilla/show_bug.cgi?id=32779 Sam James changed: What|Removed |Added CC||sam at gentoo dot org -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/20535] DSO1 needed by DSO2 linked into executable not found without -rpath-link, even though DT_RPATH and -rpath would find it
https://sourceware.org/bugzilla/show_bug.cgi?id=20535 Sam James changed: What|Removed |Added CC||sam at gentoo dot org -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/16936] $ORIGIN in shared library's rpath not used to find library dependencies at link time
https://sourceware.org/bugzilla/show_bug.cgi?id=16936 Sam James changed: What|Removed |Added CC||sam at gentoo dot org -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/20535] DSO1 needed by DSO2 linked into executable not found without -rpath-link, even though DT_RPATH and -rpath would find it
https://sourceware.org/bugzilla/show_bug.cgi?id=20535 Sam James changed: What|Removed |Added Target Milestone|--- |2.28 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/32732] Binutils (objcopy) generates abnormally large, non-functional binaries since 121a3f4b4f4aac216abe239f6f3bd491b63e5e34
https://sourceware.org/bugzilla/show_bug.cgi?id=32732 Jan Beulich changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2025-03-10 CC||jbeulich at suse dot com --- Comment #2 from Jan Beulich --- In the course of trying to adapt the testcase that the original patch added, to fit the (vaguely) change proposed in https://sourceware.org/pipermail/binutils/2025-March/139831.html I came to wonder what the original purpose of that change was: --section-alignment, like several other command line options controlling pe_* variables, is imo supposed to affect PE binaries only. Object files should be left alone. This can perhaps be seen even more prominently by the odd side effect --subsystem has on object files (for certain option arguments) with the original change in place. That option yet more clearly ought to be entirely benign to object files (and we may even want to warn about use of such options on object files). For executables, however, playing with section alignment is pointless, as section alignment is deliberately omitted from section table entries there (as of Alan's 6f8f6017a0c4 ["PR27567, Linking PE files adds alignment section flags to executables"]). Furthermore --set-section-alignment is what is (aiui) supposed to be used when trying to control alignment of sections in an object file. (I have a patch to enable the binutils-all/set-section-alignment test for COFF as well, but I first need to see how well it fares over a fuller range of targets.) Therefore my question is: Shouldn't we revert the non-auxiliary part of that change (and even backport that to at least 2.44)? Or at least, extending the patch sent to Bastian, also drop the inner if() from the conditional in question? Orthogonal to the issue here, but an observation while looking at that change in detail: In the VMA and LMA checks added, why is it "alignment != bfd_section_alignment (isection)" rather than "alignment > bfd_section_alignment (isection)"? Reducing alignment, after all, isn't going to break a section that was already misaligned. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/26806] Suspected linker bug with LTO
https://sourceware.org/bugzilla/show_bug.cgi?id=26806 Sam James changed: What|Removed |Added See Also||https://sourceware.org/bugz ||illa/show_bug.cgi?id=26314 -- You are receiving this mail because: You are on the CC list for the bug.
