On Sat, 26 Jan 2019, Dominique Martinet wrote: > 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. The problem is your gcc build requires libgcc_s.so.1 which is the i386 version; the x86_64 version is libgcc_s.so.1()(64bit) . So something has gone wrong in your build process. Michael Young _______________________________________________ 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
