Jonathan Wakely wrote on Fri, Jan 25, 2019 at 05:06:09PM +0000: >> I think it would help having more people test things, and if there are >> build failures would help package owners fix these - it's not always >> obvious to fix a build failure by repeatedly submitting a new package to >> build, and everyone doesn't have a rawhide install around. > > That's what 'mock' is for. Sure, I guess that was a bad argument; as I said I'm not maintaining packages so I can't do that for the tools where I'd have liked to test the new gcc. > >It's probably just me being lazy, though; I'll figure something out if > >there is no such plan :) > > It's really easy to build it yourself: > https://gcc.gnu.org/wiki/InstallingGCC > > Installing binutils is also simple. Build binutils and install it > first, then build GCC to use the same prefix as you installed binutils > to, and the new GCC will automatically use the new GCC. Sure, building a new toolchain is easy; that's one of the many possibilities there are to test it. One could also just use `dnf --installroot=/tmp/foo --releasever=30 isntall gcc` to pop a new chroot, or install rawhide in a VM, but all of these solutions take disk space and aren't systematically used when building stuff so it makes the testing a much more conscious action than just install some rpm and start using it. (yes, if I build a toolchain I could just add it to my PATH and it would just work as well; as I said, I'm just lazy.) Honestly, I also figured dropping the existing fc30 srpm for gcc followed by libtools and friends in a fc29 copr would be even simpler for everyone - copr really is a great tool to test new utility versions, and most of the time it just works. Turns out I wasn't correct here as for some reason gcc9 does build fine but I can't get it to install in a chroot, feel free to try my attempt if you can figure why: https://copr.fedorainfracloud.org/coprs/martinetd/gcc9/ I could upgrade libgcc/libgomp/libstdc++ (in a chroot without gcc) but trying to install gcc itself yields: Problem: package gcc-9.0.1-0.1.fc29.x86_64 requires libgcc_s.so.1, but none of the providers can be installed - libgcc-8.2.1-6.fc29.i686 has inferior architecture - libgcc-8.2.1-2.fc29.i686 has inferior architecture - cannot install both libgcc-8.2.1-6.fc29.x86_64 and libgcc-9.0.1-0.1.fc29.x86_64 - cannot install both libgcc-8.2.1-2.fc29.x86_64 and libgcc-9.0.1-0.1.fc29.x86_64 - package gcc-9.0.1-0.1.fc29.x86_64 requires libgcc >= 9.0.1-0.1.fc29, but none of the providers can be installed - cannot install the best candidate for the job while it really looks to me that it should be provided by the newer libgcc? # rpm -q --provides libgcc libgcc = 9.0.1-0.1.fc29 libgcc(x86-64) = 9.0.1-0.1.fc29 libgcc_s.so.1()(64bit) libgcc_s.so.1(GCC_3.0)(64bit) libgcc_s.so.1(GCC_3.3)(64bit) libgcc_s.so.1(GCC_3.3.1)(64bit) libgcc_s.so.1(GCC_3.4)(64bit) libgcc_s.so.1(GCC_3.4.2)(64bit) libgcc_s.so.1(GCC_3.4.4)(64bit) libgcc_s.so.1(GCC_4.0.0)(64bit) libgcc_s.so.1(GCC_4.2.0)(64bit) libgcc_s.so.1(GCC_4.3.0)(64bit) libgcc_s.so.1(GCC_4.7.0)(64bit) libgcc_s.so.1(GCC_4.8.0)(64bit) libgcc_s.so.1(GCC_7.0.0)(64bit) So, meh, I'll probably pick something else but I don't like not understanding why something doesn't work. -- Dominique _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
