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