|
Bugzilla – Full Text Bug Listing |
| Summary: | gcc15: rpm package needs to request newer binutils | ||
|---|---|---|---|
| Product: | [openSUSE] openSUSE Tumbleweed | Reporter: | Jan Engelhardt <jengelh> |
| Component: | Development | Assignee: | Richard Biener <rguenther> |
| Status: | NEW --- | QA Contact: | E-mail List <qa-bugs> |
| Severity: | Normal | ||
| Priority: | P5 - None | CC: | rguenther |
| Version: | Current | ||
| Target Milestone: | --- | ||
| Hardware: | x86-64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Found By: | --- | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
You need to install binutils from devel:gcc:next as well, yes. The packages are more for continous build testing rather than user consumption so I'm unsure as to whether to amend Requires here. It often varies by target what exact minimal binutils version is required and thus whether the one from Factory is recent enough. GCC detects binutils features available at build time and we're using binutils from git here to get maximum QA. >GCC detects binutils features available at build time
That sounds much like
%requires_ge binutils
is warranted.
(In reply to Jan Engelhardt from comment #2) > >GCC detects binutils features available at build time > > That sounds much like > > %requires_ge binutils > > is warranted. Sure but isn't such versioned require "implicit" for all requires we have in Factory? So I don't see how this is much different here - you are using an alternate repository and so you should "update" from it? That means we should in general never have unversioned requires? >isn't such versioned require "implicit" for all requires we have in Factory? Nope. (That's only implicit when you do `zypper dup`, and then only if Factory is not giving the user any downgrades.) >So I don't see how this is much different here - you are using an alternate repository and so you should "update" from it? Just zypper dup # get existing TW install up to speed zypper ar obs://devel:gcc:next gn zypper in gcc15-c++ that did not propose any new binutils. (In reply to Jan Engelhardt from comment #4) > >isn't such versioned require "implicit" for all requires we have > in Factory? > > Nope. (That's only implicit when you do `zypper dup`, and then only if > Factory is not giving the user any downgrades.) > > >So I don't see how this is much different here - you are using > an alternate repository and so you should "update" from it? > > Just > > zypper dup # get existing TW install up to speed > zypper ar obs://devel:gcc:next gn > zypper in gcc15-c++ > > that did not propose any new binutils. Yes, I understand. I wonder if I should in general have GCC depend on the binutils it was built with; but as there's only a single binutils in Factory that would be odd precedent. This is a package from an experimental project (it's not even the devel project - there we avoid this by building against the distro packages), I doubt any other experimental or even devel project with packages having inter-dependences worry about this. |
gcc15-15.0.0+git2210-20.1.x86_64 from devel:gcc:next needs a Requires: binutils >= {something} because it exercises a feature not present in Tumbleweed's current binutils-2.42(TW): $ gcc-15 -DHAVE_CONFIG_H -I. -I.. -D_FILE_OFFSET_BITS=64 -D_REENTRANT -I../include -Wall -Waggregate-return -Wmissing-declarations -Wmissing-prototypes -Wredundant-decls -Wshadow -Wstrict-prototypes -Wformat=2 -O0 -ggdb3 -MT format.lo -MD -MP -MF .deps/format.Tpo -c format.c -fPIC -DPIC -o .libs/format.o -save-temps .libs/format.s: Assembler messages: .libs/format.s:257: Error: unknown pseudo-op: `.base64' .libs/format.s:2253: Error: unknown pseudo-op: `.base64' format.s:: -.LC0: - .string "\t\n\013 " +.LC0: + .base64 "CQoLIAA="