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