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@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org
