gdb fails to build with Python 3.9.0a5. libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../../bfd -DBINDIR=\"/usr/bin\" -DLIBDIR=\"/usr/lib64\" -I. -I../../bfd -I../../bfd/../include -DHAVE_x86_64_elf64_vec -DHAVE_i386_elf32_vec -DHAVE_iamcu_elf32_vec -DHAVE_x86_64_elf32_vec -DHAVE_i386_pei_vec -DHAVE_x86_64_pei_vec -DHAVE_l1om_elf64_vec -DHAVE_k1om_elf64_vec -DHAVE_elf64_le_vec -DHAVE_elf64_be_vec -DHAVE_elf32_le_vec -DHAVE_elf32_be_vec -DHAVE_s390_elf32_vec -DHAVE_s390_elf64_vec -DHAVE_powerpc_elf32_vec -DHAVE_rs6000_xcoff_vec -DHAVE_powerpc_elf32_le_vec -DHAVE_powerpc_boot_vec -DHAVE_powerpc_elf64_vec -DHAVE_powerpc_elf64_le_vec -DHAVE_arm_elf32_le_vec -DHAVE_arm_elf32_fdpic_le_vec -DHAVE_arm_elf32_be_vec -DHAVE_arm_elf32_fdpic_be_vec -DHAVE_aarch64_elf64_le_vec -DHAVE_aarch64_elf64_be_vec -DHAVE_aarch64_elf32_le_vec -DHAVE_aarch64_elf32_be_vec -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow -Wstack-usage=262144 -Werror -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -MT elf.lo -MD -MP -MF .deps/elf.Tpo -c ../../bfd/elf.c -o elf.o ../../bfd/elf.c: In function 'setup_group': ../../bfd/elf.c:752:35: error: overflow in conversion from 'unsigned int' to 'int' changes value from 'num_group = 4294967295' to '-1' [-Werror=overflow] 752 | elf_tdata (abfd)->num_group = num_group = -1; | ^~~~~~~~~ mv -f .deps/elf64.Tpo .deps/elf64.Plo For the build logs, see: https://copr-be.cloud.fedoraproject.org/results/@python/python3.9/fedora-rawhide-x86_64/01321687-gdb/ For all our attempts to build gdb with Python 3.9, see: https://copr.fedorainfracloud.org/coprs/g/python/python3.9/package/gdb/ Testing and mass rebuild of packages is happening in copr. You can follow these instructions to test locally in mock if your package builds with Python 3.9: https://copr.fedorainfracloud.org/coprs/g/python/python3.9/ Let us know here if you have any questions. Python 3.9 will be included in Fedora 33. To make that update smoother, we're building Fedora packages with early pre-releases of Python 3.9. A build failure prevents us from testing all dependent packages (transitive [Build]Requires), so if this package is required a lot, it's important for us to get it fixed soon. We'd appreciate help from the people who know this package best, but if you don't want to work on this now, let us know so we can try to work around it on our side.
Setting the severity to high. This package is part of the initial bootstrap sequence. Without it, we cannot proceed with the Python 3.9 bootstrap in a Koji side tag. https://fedoraproject.org/wiki/Changes/Python3.9#Important_dates_and_plan The current plan is to follow the "ideal point when we can start rebuilding in Koji" -- that is we need to get this bug fixed approximately in 1 month and 1 week. That includes potential uncovered bugs in packages that depend on this one. Please acknowledge that you have read this message and that you can dedicate time to fix it. If you know already that you won't be able to fix it by the deadline, please let us know ASAP, so we can allocate resources to do that. Thank You.
Sorry for the delay, I am aware of the issue and will try to fix it ASAP.
Thanks!
Just an update on this. Kevin is looking into fixing it, but the bug seems to be related to binutils, and not GDB. We might have to reassign it. Also, I'd be interested in knowing why this error (which seems to be completely unrelated to the Python support on GDB) happens on the copr repository, but not on Rawhide. I'm assuming the GCC being used is newer than the one available on Rawhide.
> Also, I'd be interested in knowing why this error (which seems to be completely unrelated to the Python support on GDB) happens on the copr repository, but not on Rawhide. That is a mystery to me as well. There are root logs in case you want to compare them with rawhide root logs. For the gdb build, this is from our repo: libbabeltrace-devel x86_64 1.5.8-1.fc33 libselinux-devel x86_64 3.0-4.fc33 python3-devel x86_64 3.9.0~a5-1.fc33 rpm-devel x86_64 4.15.90-0.git14971.3.fc33 boost x86_64 1.69.0-16.fc33 boost-atomic x86_64 1.69.0-16.fc33 boost-chrono x86_64 1.69.0-16.fc33 boost-container x86_64 1.69.0-16.fc33 boost-context x86_64 1.69.0-16.fc33 boost-contract x86_64 1.69.0-16.fc33 boost-coroutine x86_64 1.69.0-16.fc33 boost-date-time x86_64 1.69.0-16.fc33 boost-devel x86_64 1.69.0-16.fc33 boost-fiber x86_64 1.69.0-16.fc33 boost-filesystem x86_64 1.69.0-16.fc33 boost-graph x86_64 1.69.0-16.fc33 boost-iostreams x86_64 1.69.0-16.fc33 boost-locale x86_64 1.69.0-16.fc33 boost-log x86_64 1.69.0-16.fc33 boost-math x86_64 1.69.0-16.fc33 boost-program-options x86_64 1.69.0-16.fc33 boost-random x86_64 1.69.0-16.fc33 boost-regex x86_64 1.69.0-16.fc33 boost-serialization x86_64 1.69.0-16.fc33 boost-stacktrace x86_64 1.69.0-16.fc33 boost-system x86_64 1.69.0-16.fc33 boost-test x86_64 1.69.0-16.fc33 boost-thread x86_64 1.69.0-16.fc33 boost-timer x86_64 1.69.0-16.fc33 boost-type_erasure x86_64 1.69.0-16.fc33 boost-wave x86_64 1.69.0-16.fc33 libbabeltrace x86_64 1.5.8-1.fc33 libblkid-devel x86_64 2.35.1-7.fc33 libmount-devel x86_64 2.35.1-7.fc33 libuuid-devel x86_64 2.35.1-7.fc33 python-pip-wheel noarch 20.0.2-2.fc33 python-setuptools-wheel noarch 46.1.3-1.fc33 python3 x86_64 3.9.0~a5-1.fc33 python3-libs x86_64 3.9.0~a5-1.fc33 python3-rpm-generators noarch 11-1.fc33 python3-setuptools noarch 46.1.3-1.fc33 rpm-sign-libs x86_64 4.15.90-0.git14971.3.fc33 Everything else is from rawhide (Koji repo). > I'm assuming the GCC being used is newer than the one available on Rawhide. We don't build newer gcc in that repo.
FWIW, I was able to reproduce the problem on Rawhide (outside mock). Even though this is a binutils problem, we should be able to fix this on GDB as well (since GDB carries its own copy of bfd).
The following commit fixed the issue upstream: commit cda7e5603f6efd7c3716e45cc6ea11b70dd8daae Author: H.J. Lu <hjl.tools> Date: Tue Mar 24 04:52:39 2020 -0700 bfd: Change num_group to unsigned int
The i686/armv7hl buildroots seem to have some problem: https://koji.fedoraproject.org/koji/taskinfo?taskID=43142207 We don't know why this segfault is happening, since we haven't changed anything else other than backport the patch (which is extremely simple). We'll try to find out what's going on.
I think this should now be fixed in gdb-9.1-5.
Indeed it is. There is another failure with Python 3.9. I've opened a new bugzilla, bz1822715.
FEDORA-2020-0bc8abfe7d has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2020-0bc8abfe7d
FEDORA-2020-0bc8abfe7d has been pushed to the Fedora 32 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-0bc8abfe7d` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-0bc8abfe7d See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2020-0bc8abfe7d has been pushed to the Fedora 32 stable repository. If problem still persists, please make note of it in this bug report.