[Bug binutils/27128] nm -P portable output format regression
https://sourceware.org/bugzilla/show_bug.cgi?id=27128 Alan Modra changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|2.36|2.37 --- Comment #11 from Alan Modra --- Fixed as best we can. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/27441] Small inconsistency in between gold and bfd
https://sourceware.org/bugzilla/show_bug.cgi?id=27441 --- Comment #21 from Fangrui Song --- I made a mistake in #comment 16. In GNU ld, the rule is probably: * it is linked at least once in `--no-as-needed` mode (i.e. `--as-needed a.so --no-as-needed a.so` => needed) * or it has a definition resolving a non-weak reference by a previous input file (it works similar to archive member selection) In gold, the rule is probably: * it is linked at least once in `--no-as-needed` mode (i.e. `--as-needed a.so --no-as-needed a.so` => needed) * or it has a definition resolving a non-weak reference In LLD, a shared object is needed, if one of the following conditions is true: * it is linked at least once in `--no-as-needed` mode (i.e. `--as-needed a.so --no-as-needed a.so` => needed) * or it has a definition resolving a non-weak reference from a live section (not discarded by `--gc-sections`) Yes, the GNU ld behavior matches its documentation. But gold and LLD's behaviors are probably more useful (less reliance on position dependent behaviors - the user has more freedom moving it around on the linker command line without changing symbol resolution) and can make implementation simpler (no need to handle --as-needed shared object similar to the tricky archive member selection) # a.s call foo # b.s .globl foo foo: ret gold --as-needed b.so a.o && readelf -d a.out ... 0x0001 (NEEDED) Shared library: [b.so] -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libctf/27360] libctf.so.0: undefined symbol: bsearch_r
https://sourceware.org/bugzilla/show_bug.cgi?id=27360 --- Comment #6 from Allan McRae --- I can still replicate on git master (160fe1933736c123e15199080874fcab8b9ecc65). I build with the following configuration: CFLAGS="-march=x86-64 -mtune=generic -O2 -pipe -fno-plt" CXXFLAGS="-march=x86-64 -mtune=generic -O2 -pipe -fno-plt" LDFLAGS="-Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now" ../binutils-gdb/configure \ --prefix=/usr \ --with-lib-path=/usr/lib:/usr/local/lib \ --with-bugurl=https://bugs.archlinux.org/ \ --enable-cet \ --enable-deterministic-archives \ --enable-gold \ --enable-ld=default \ --enable-lto \ --enable-plugins \ --enable-relro \ --enable-shared \ --enable-targets=x86_64-pep \ --enable-threads \ --disable-gdb \ --disable-werror \ --with-debuginfod \ --with-pic \ --with-system-zlib Removing "--enable-shared" from configre, or "-fno-plt" from CFLAGS or "-Wl,-z,now" from LDFLAGS does not give this error. Not ld in the build tree is fine. It is the installed file (which is relinked during "make install") that shows the issue. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/27495] -z start_stop_gc isn't compatible with static glibc
https://sourceware.org/bugzilla/show_bug.cgi?id=27495 --- Comment #10 from H.J. Lu --- They fail at random on both i686 and x86-64. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libctf/27360] libctf.so.0: undefined symbol: bsearch_r
https://sourceware.org/bugzilla/show_bug.cgi?id=27360 Nick Alcock changed: What|Removed |Added Assignee|unassigned at sourceware dot org |nick.alcock at oracle dot com -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libctf/27297] libctf.a malformed, build fails on x86_64-apple-darwin18.7.0
https://sourceware.org/bugzilla/show_bug.cgi?id=27297 --- Comment #7 from Nick Alcock --- Quite possibly, or at least I don't see that failure with the reported replication mechanism on binutils master: I'll update that bug too. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libctf/27360] libctf.so.0: undefined symbol: bsearch_r
https://sourceware.org/bugzilla/show_bug.cgi?id=27360 Nick Alcock changed: What|Removed |Added Status|UNCONFIRMED |WAITING Ever confirmed|0 |1 CC||nick.alcock at oracle dot com Last reconfirmed||2021-03-09 --- Comment #5 from Nick Alcock --- This suggests that libctf.so has not had needed symbols from libiberty built into it properly (and bsearch_r is not called on by anything else in ld, so ld will fail). This is quite strange given that we are still linking -liberty in even after that commit. At any rate, I do not see this with binutils master, so it's quite likely that the fixes for bug 27297 fixed this too (even if I have no immediate idea why it happened in the first place). Could you try it and see? (If so, I guess I'll have to backport this pile of commits to stable, even though I was hoping to avoid doing so because it affects a lot of things other than just ld.) -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libctf/27297] libctf.a malformed, build fails on x86_64-apple-darwin18.7.0
https://sourceware.org/bugzilla/show_bug.cgi?id=27297 Yichao Yu changed: What|Removed |Added CC||yyc1992 at gmail dot com --- Comment #6 from Yichao Yu --- Does any of the patches also fixed https://sourceware.org/bugzilla/show_bug.cgi?id=27360 ? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/27551] New: The default encoding of the strings utility does not conform to POSIX: should honor the current locale.
https://sourceware.org/bugzilla/show_bug.cgi?id=27551 Bug ID: 27551 Summary: The default encoding of the strings utility does not conform to POSIX: should honor the current locale. Product: binutils Version: 2.35.2 Status: UNCONFIRMED Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: vincent-srcware at vinc17 dot net Target Milestone: --- The default encoding of the "strings" utility is documented to be "single-7-bit-byte characters", i.e. ASCII. But https://pubs.opengroup.org/onlinepubs/9699919799/utilities/strings.html says: LC_CTYPE Determine the locale for the interpretation of sequences of bytes of text data as characters (for example, single-byte as opposed to multi-byte characters in arguments and input files) and to identify printable strings. I get: zira% printenv LC_CTYPE C.UTF-8 zira% echo abcdéfghi | strings abcd fghi while "strings" should have output: abcdéfghi -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/27441] Small inconsistency in between gold and bfd
https://sourceware.org/bugzilla/show_bug.cgi?id=27441 --- Comment #20 from Michael Matz --- (In reply to Cary Coutant from comment #18) > > > My understanding of when a shared object is needed: > > > > > > * it is linked at least once in --no-as-needed mode (i.e. --as-needed a.so > > > --no-as-needed a.so => needed) > > > * or it has a non-weak definition resolving a reference from a live > > > section > > > (not discarded by --gc-sections) > > > > > > I think both LLD and gold's rules are like this. > > > > Then they both have the same bug (in the second item of your list). As Alan > > explains, as-needed behaviour intends to reflect behaviour of static > > archives > > (where that applies; here any difference in behaviour doesn't seem useful). > > > > The only thing about weak definitions is that there may be validly multiple > > ones > > without error (the first one or the single non-weak definition wins). > > This contradicts the ld manual: > ... > Note where it says "that at that point in the link satisfies a *non-weak* > undefined symbol reference from a regular object file or, if the library is > not found in the DT_NEEDED lists of other needed libraries, a *non-weak* > undefined symbol reference from another needed dynamic library." (emphasis > added) Right. This describes the static archive extraction rules. It talks about (non-weak i.e. strong) references, not about (weak) definitions. Weak (and strong) definitions do satisfy strong references, and hence invoke the above rules about archive member extraction (and therefore should then also cause the same behaviour for DT_NEEDED). -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/27550] boldface entity names in chapter Acknowledgements
https://sourceware.org/bugzilla/show_bug.cgi?id=27550 Christopher Yeleighton changed: What|Removed |Added URL||info:/as/Acknowledgements -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/27550] New: boldface entity names in chapter Acknowledgements
https://sourceware.org/bugzilla/show_bug.cgi?id=27550
Bug ID: 27550
Summary: boldface entity names in chapter Acknowledgements
Product: binutils
Version: 2.36
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: gas
Assignee: unassigned at sourceware dot org
Reporter: giecrilj at stegny dot 2a.pl
Target Milestone: ---
e.g. @b{Nick Clifton}
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug gas/27549] There are no "AArch64‑dependent features"
https://sourceware.org/bugzilla/show_bug.cgi?id=27549 Christopher Yeleighton changed: What|Removed |Added Summary|There are no|There are no |AArch64‑dependent Features |"AArch64‑dependent ||features" URL||info:/as/Machine ||Dependencies -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/27549] New: There are no AArch64‑dependent Features
https://sourceware.org/bugzilla/show_bug.cgi?id=27549 Bug ID: 27549 Summary: There are no AArch64‑dependent Features Product: binutils Version: 2.36 Status: UNCONFIRMED Severity: minor Priority: P2 Component: gas Assignee: unassigned at sourceware dot org Reporter: giecrilj at stegny dot 2a.pl Target Milestone: --- The machine‑dependent features for AArch64 are AArch64‑specific, not AArch64‑dependent. We do not say that anything depends on a constant; this would be a misleading statement. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/27550] boldface entity names in chapter Acknowledgements
https://sourceware.org/bugzilla/show_bug.cgi?id=27550 Christopher Yeleighton changed: What|Removed |Added Severity|normal |enhancement -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/27538] Wrong summary for alternate option at as/Invoking
https://sourceware.org/bugzilla/show_bug.cgi?id=27538 Christopher Yeleighton changed: What|Removed |Added Version|unspecified |2.36 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/26706] pad strings in .dynstr
https://sourceware.org/bugzilla/show_bug.cgi?id=26706 --- Comment #4 from Mark Wielaard --- Hi Ben, Bugzilla tricked you and changed the from so your reply went directly into the bug. On Tue, Mar 09, 2021 at 12:41:46AM +, woodard at redhat dot com wrote: > https://sourceware.org/bugzilla/show_bug.cgi?id=26706 > > --- Comment #3 from Ben Woodard --- > Do you think it is worth me chiming in saying ‘what he said’? You captured my > intent perfectly. I guess I’m kind of hung up on “assume” in “what I assume > Ben, the original reporter, is after” or is that just a polite assume. So you just did chime in with an "what he said". Thanks! Of course it was a polite assume, I always try to be polite :) Just didn't want to put any words in your mouth, even though I was pretty sure because we had discussed the way Solaris solved it before. Just wanted to provide some background pointers. But yes, it probably should have read "what I know", but that sounded so presumptious. Cheers, Mark -- You are receiving this mail because: You are on the CC list for the bug.
