Learn more about these different git repos.
Other Git URLs
Describe the issue A new release of the GNU Binutils is about to happen (version 2.35). This change request is to alert people to the change and allow a chance for any concerns to be raised. (None are expected though).
When do you need this? (YYYY/MM/DD) 2020/07/27
When is this no longer needed or useful? (YYYY/MM/DD) 2021/01/31
If we cannot complete your request, what is the impact? The binutils in rawhide will be an older version, with fewer bug fixes and features.
Is releng tracker the right forum for this to alert people?
I believe that just link to the change page is missing here :)
True - but the change page cannot be created at the moment because the Fedora Project services are currently unavailable... I will add a link once the services are back and the page has been created.
@nickc Since I cannot see the change, do you expect a mass rebuild for this change?
Metadata Update from @mohanboddu: - Issue tagged with: changes, f33
@nickc Since I cannot see the change, do you expect a mass rebuild for this change? Yes please. Since the binutils package contains the assembler and linker, a mass rebuild would be a good idea.
The change request has now been created:
https://fedoraproject.org/wiki/Changes/BINUTILS235
Metadata Update from @mohanboddu: - Issue tagged with: change-ack, mass rebuild
@nickc Whats the status on this? I dont see binutils-2.35 yet, mass rebuild is scheduled for next week.
The 2.35 release is this weekend. I should have the new version installed on Monday.
Thanks @nickc for the update, please keep us posted as we delayed the mass rebuild for Fri, we could delay it for Mon as well. Thanks again.
The rebase has now been completed.
Closing the ticket as the work here is done.
Metadata Update from @mohanboddu: - Issue close_status updated to: Fixed - Issue status updated to: Closed (was: Open)
@nickc and others,
regarding
as well as support for DWARF-5 format line number tables
just recently I noticed some strange remarks wrt. decoding DWARF in bt of gdb. This update solved this for me:
bt
gdb
Upgrade gdb-10.1-4.fc34.x86_64 @rawhide Upgraded gdb-9.1-5.fc33.x86_64 @@System Upgrade gdb-headless-10.1-4.fc34.x86_64 @rawhide Upgraded gdb-headless-9.1-5.fc33.x86_64 @@System
No idea how intertwined this is and whether it had any relevance to this change, but my guess says: could be.
Don't we want to avoid official distro -debuginfo packages causing this trouble and Recommends: appropriate minimal version of gdb?
-debuginfo
Recommends:
Or would something like (gdb >= 10 if gdb) work?
(gdb >= 10 if gdb)
Any other idea how to softly push for update of gdb for debugging scenarios where desirable regarding the user experience?
FTR. there has been some change-detached ML thread: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/KFMSEV2JO2TIHNHVJFGTI5ZIEM4GIFDG/
@jpokorny Isn't the only way this can happen the result of a partial upgrade to rawhide?
@fweimer Or living at Rawhide perpetually, and updating selectively, which should be pretty valid, shouldn't it? Otherwise, there would be no reason for up-to-version-resolution dependency tracking and such, when you could say "you need to always update the full sync".
There are various reasons for this on my side, and that dnf is unable to split the upgrade batch doesn't help.
dnf
Dependency systems are here to enforce sane boundaries to the otherwise mix&match freedom, correct?
Also, specifically in Rawhide, it proved useful to me to rather update piece-wise, it's much easier to identify the culprit and rollback.
Time-distant full-blown updates is sometimes a Russian roulette.
Also, I can imagine some people prioritize just security updates.
And tangential is also this issue as a fallout from not having interdependencies of the whole toolchain credibly reflecting the lockstep that is otherwise intrinsically assumed:
$ /usr/bin/gcc -Wall -g -c -o module.o module.c > as: unrecognized option '--gdwarf-5' $ /usr/bin/gcc -v |& grep specs > Using built-in specs. $ strace -e trace=file /usr/bin/gcc -dumpspecs \ |& grep -v -e '\(.*at(.*\|/usr/.*/locale/.*\|/usr/bin/.*\|/lib64/lib.*\)' \ | grep -B1 -e gdwarf -e '^[a-z].*(' > access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory) > readlink("/usr", 0x7ffd69161870, 1023) = -1 EINVAL (Invalid argument) > readlink("/usr/bin", 0x7ffd69161870, 1023) = -1 EINVAL (Invalid argument) > readlink("/usr", 0x7ffd69161870, 1023) = -1 EINVAL (Invalid argument) > readlink("/usr/bin", 0x7ffd69161870, 1023) = -1 EINVAL (Invalid argument) > -- > *asm_debug_option: > %{%:debug-level-gt(0):%{!gstabs*:%{g*:%{%:dwarf-version-gt(4):--gdwarf-5 ;%:dwarf-version-gt(3):--gdwarf-4 ;%:dwarf-version-gt(2):--gdwarf-3 ;:--gdwarf2 }}}}
(so indeed, gcc is not sourcing any specs from anywhere)
gcc
specs
$ rpm -qf /usr/bin/{gcc,as} > gcc-11.0.0-0.18.fc34.x86_64 > binutils-2.34-2.fc33.x86_64
Not constraining the dependencies truthfully leads to such "impedance mismatches".
Login to comment on this ticket.