Hi,
we are currently trying to get openSUSE:Factory:Rings:0-Bootstrap and openSUSE:Factory:Rings:1-MinimalX clean to build with GCC 5 in the openSUSE:Factory:Staging:Gcc49 project. Once that works reasonably I will push GCC 5 to Factory without enabling it as a default - that will be done when it works fully (help appreciated at that point).
There is a porting-to document that explains some issues you may run into (also consider the 4.9 variant as we didn't transition to that): https://gcc.gnu.org/gcc-5/porting_to.html https://gcc.gnu.org/gcc-4.9/porting_to.html
You may also find the analysis of Fedora interesting which explains why some packages now fail to build: https://lists.fedoraproject.org/pipermail/devel/2015-February/207549.html
GCC 5 packages can be installed from devel:gcc where they are regularly updated. Those sources also feed openSUSE:Factory:Staging:Gcc49.
Richard.
On Tue, Feb 10, Richard Biener wrote:
we are currently trying to get openSUSE:Factory:Rings:0-Bootstrap and openSUSE:Factory:Rings:1-MinimalX clean to build with GCC 5 in the openSUSE:Factory:Staging:Gcc49 project. Once that works reasonably I will push GCC 5 to Factory without enabling it as a default - that will be done when it works fully (help appreciated at that point).
Please add "-Werror=date-time" to the global CFLAGS in that project.
Olaf
On Wed, 11 Feb 2015, Olaf Hering wrote:
On Tue, Feb 10, Richard Biener wrote:
we are currently trying to get openSUSE:Factory:Rings:0-Bootstrap and openSUSE:Factory:Rings:1-MinimalX clean to build with GCC 5 in the openSUSE:Factory:Staging:Gcc49 project. Once that works reasonably I will push GCC 5 to Factory without enabling it as a default - that will be done when it works fully (help appreciated at that point).
Please add "-Werror=date-time" to the global CFLAGS in that project.
Why should I do that and make my life harder?
Richard.
On Wed, Feb 11, Richard Biener wrote:
On Wed, 11 Feb 2015, Olaf Hering wrote:
Please add "-Werror=date-time" to the global CFLAGS in that project.
Why should I do that and make my life harder?
Makes our life easier, and failures resulting from that change will be fixed quickly.
Olaf
On Wed, 11 Feb 2015, Olaf Hering wrote:
On Wed, Feb 11, Richard Biener wrote:
On Wed, 11 Feb 2015, Olaf Hering wrote:
Please add "-Werror=date-time" to the global CFLAGS in that project.
Why should I do that and make my life harder?
Makes our life easier, and failures resulting from that change will be fixed quickly.
You can roll your own staging project for that. I have enough FAILs to look at already.
Richard.
On 02/10/2015 08:21 PM, Richard Biener wrote:
Hi,
we are currently trying to get openSUSE:Factory:Rings:0-Bootstrap and openSUSE:Factory:Rings:1-MinimalX clean to build with GCC 5 in the openSUSE:Factory:Staging:Gcc49 project. Once that works reasonably I will push GCC 5 to Factory without enabling it as a default - that will be done when it works fully (help appreciated at that point).
There is a porting-to document that explains some issues you may run into (also consider the 4.9 variant as we didn't transition to that): https://gcc.gnu.org/gcc-5/porting_to.html https://gcc.gnu.org/gcc-4.9/porting_to.html
You may also find the analysis of Fedora interesting which explains why some packages now fail to build: https://lists.fedoraproject.org/pipermail/devel/2015-February/207549.html
GCC 5 packages can be installed from devel:gcc where they are regularly updated. Those sources also feed openSUSE:Factory:Staging:Gcc49.
Richard.
I noticed today while reading the Qt mailing list that Qt 4 doesn't build currently due to a gcc bug, https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65062 The relevant email is below,
PS i'm not part of the openSUSE Qt team, but this will probably save someone some time.
Message: 6 Date: Fri, 13 Feb 2015 18:46:29 -0800 From: Thiago Macieirathiago.macieira@intel.com Subject: Re: [Development] qt-4.8.6 + gcc5 fails to build ? To:development@qt-project.org Message-ID: 1648052.am1N8n1sCm@tjmaciei-mobl4 Content-Type: text/plain; charset="us-ascii"
On Friday 13 February 2015 14:21:09 Thiago Macieira wrote:
On Friday 13 February 2015 11:37:27 Rex Dieter wrote:
Fedora development has recently adopted gcc5, and we've run into several problems, one of which is that qt-4.8.6 fails to build, when linking libQtGui:
.obj/release-shared/qdrawhelper_sse2.o: In function `unsigned int const* qt_fetch_radial_gradient_template<QRadialFetchSimd<QSimdSse2> >(unsigned int*, Operator const*, QSpanData const*, int, int, int)': /builddir/build/BUILD/qt-everywhere-opensource- src-4.8.6/src/gui/../../include/QtGui/private/../../../src/gui/painting/qd ra whelper_p.h:396: undefined reference to `qt_memfill32' collect2: error: ld returned 1 exit status
same problem with latest 4.8.7 2015-02-02-3 snapshot.
Currently tracking issue @ https://bugreports.qt.io/browse/QTBUG-44466
anyone with similar or different experiences?
It's a GCC bug. One file defines a symbol "qt_memfill32" and the other searches for "_Z12qt_memfill32".
GCC 4.9, Clang and ICC don't have this problem. Therefore, it's a GCC bug.
Reported:https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65062
Testcase: template <class> void tf() { extern void (*qt_memfill32)(); qt_memfill32(); }
void f() { tf<int>(); }
The project to get packages to build with GCC 5 which we should try to transition to has progressed but is not yet finished.
https://build.opensuse.org/project/show/openSUSE:Factory:Staging:Gcc49
currently shows 13 package build fails and 59 packages not built due to failed requirements.
Of the packages that fail building some of them have patches from me either in SR state or just in the devel projects which have not been pushed to Factory.
Currently unfixed packages include (at least)
coreutils mariadb pinentry post-build-checks python3-base reiserfs shim yast2-core libzypp memtest86+ xen
both libzypp and yast2-core are responsible for nearly all 59 packages in unresolved state (there is xen that also causes some unresolvables)
I especially ask maintainers of packages that have got a fix from me for their package but didn't yet push that fix to Factory to do that.
And I am asking the yast/zypp people to look at their packages.
As openSUSE:Factory:Staging:Gcc49 only builds the set of packages to build the Minimal+X media the whole list of packages failing with GCC 5 will be larger - you are encouraged to add a repository building against openSUSE:Factory:Staging:Gcc49 to your devel project if it covers sth that can be built against Minimal+X (KDE & GNOME stack?)
Thanks, Richard.
On Tue, Mar 24, 2015 at 8:15 AM, Richard Biener rguenther@suse.de wrote:
pinentry reiserfs memtest86+
I fixed those yesterday.
xen
There is an old xen in that project, the current version in the devel project does not fail.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 24.03.2015 16:02, Cristian Rodríguez wrote:
On Tue, Mar 24, 2015 at 8:15 AM, Richard Biener rguenther@suse.de wrote:
pinentry reiserfs memtest86+
I fixed those yesterday.
xen
There is an old xen in that project, the current version in the devel project does not fail.
That's what Richard is talking about: submit your fixes!
Greetings, Stephan
On Tue, 24 Mar 2015, Cristian Rodríguez wrote:
On Tue, Mar 24, 2015 at 8:15 AM, Richard Biener rguenther@suse.de wrote:
pinentry reiserfs memtest86+
I fixed those yesterday.
Thanks.
xen
There is an old xen in that project, the current version in the devel project does not fail.
How did you check? It seems the package in the devel project needs new dependencies not in the current set of packages in openSUSE:Factory:Staging:Gcc49:
Virtualization/xen> osc build --noservice --alternative-project=openSUSE:Factory:Staging:Gcc49 standard x86_64 xen.spec WARNING: source service from package or project will not be executed. This may not be the same build as on server! Building xen.spec for standard/x86_64 Getting buildinfo from server and store to /tmp/Virtualization/xen/.osc/_buildinfo-standard-x86_64.xml Getting buildconfig from server and store to /tmp/Virtualization/xen/.osc/_buildconfig-standard-x86_64 buildinfo is broken... it says: unresolvable: nothing provides libspice-server-devel, nothing provides spice-protocol-devel, nothing provides usbredir-devel
ah, that's a x86_64-only requirement. But it seems that i586 still fails to build:
[ 80s] out/code16.o: In function `kbd_command': [ 80s] /home/abuild/rpmbuild/BUILD/xen-4.5.0-testing/tools/firmware/seabios-dir-remote/src/kbd.c:120: undefined reference to `usb_kbd_command' [ 80s] out/code16.o: In function `mouse_command': [ 80s] /home/abuild/rpmbuild/BUILD/xen-4.5.0-testing/tools/firmware/seabios-dir-remote/src/mouse.c:30: undefined reference to `usb_mouse_command' [ 80s] Makefile:170: recipe for target 'out/rom16.o' failed [ 80s] make[6]: *** [out/rom16.o] Error 1
Richard.
On Tuesday 24 March 2015 12:15:24 Richard Biener wrote:
The project to get packages to build with GCC 5 which we should try to transition to has progressed but is not yet finished.
https://build.opensuse.org/project/show/openSUSE:Factory:Staging:Gcc49
libzypp-14.38.1 builds in openSUSE_Factory_Staging_Gcc49_standard
On Tue, 24 Mar 2015, Richard Biener wrote:
The project to get packages to build with GCC 5 which we should try to transition to has progressed but is not yet finished.
https://build.opensuse.org/project/show/openSUSE:Factory:Staging:Gcc49
currently shows 13 package build fails and 59 packages not built due to failed requirements.
Of the packages that fail building some of them have patches from me either in SR state or just in the devel projects which have not been pushed to Factory.
So we are down to a handful of fails and -><- this close from building DVD images. Main offenders that prevent that are
shim -- fixed in devel project but not forwarded to factory :( yast2-auth-server, C++ error, fix sent to maintainers open-lldp -- fixed in devel project but not forwarded to factory :(
some fixes are now finally staged and should appear in factory soon (hopefully).
Please push your packages to factory.
Thanks, Richard.
On Thu, Apr 09, 2015 at 10:50:07AM +0200, Richard Biener wrote:
On Tue, 24 Mar 2015, Richard Biener wrote:
The project to get packages to build with GCC 5 which we should try to transition to has progressed but is not yet finished.
https://build.opensuse.org/project/show/openSUSE:Factory:Staging:Gcc49
currently shows 13 package build fails and 59 packages not built due to failed requirements.
Of the packages that fail building some of them have patches from me either in SR state or just in the devel projects which have not been pushed to Factory.
So we are down to a handful of fails and -><- this close from building DVD images. Main offenders that prevent that are
shim -- fixed in devel project but not forwarded to factory :( yast2-auth-server, C++ error, fix sent to maintainers open-lldp -- fixed in devel project but not forwarded to factory :(
some fixes are now finally staged and should appear in factory soon (hopefully).
Please push your packages to factory.
shim might be tricky, this might be the one Microsoft is not willing to sign currently.
Ciao, Marcus
On Thu, 9 Apr 2015, Marcus Meissner wrote:
On Thu, Apr 09, 2015 at 10:50:07AM +0200, Richard Biener wrote:
On Tue, 24 Mar 2015, Richard Biener wrote:
The project to get packages to build with GCC 5 which we should try to transition to has progressed but is not yet finished.
https://build.opensuse.org/project/show/openSUSE:Factory:Staging:Gcc49
currently shows 13 package build fails and 59 packages not built due to failed requirements.
Of the packages that fail building some of them have patches from me either in SR state or just in the devel projects which have not been pushed to Factory.
So we are down to a handful of fails and -><- this close from building DVD images. Main offenders that prevent that are
shim -- fixed in devel project but not forwarded to factory :( yast2-auth-server, C++ error, fix sent to maintainers open-lldp -- fixed in devel project but not forwarded to factory :(
some fixes are now finally staged and should appear in factory soon (hopefully).
Please push your packages to factory.
shim might be tricky, this might be the one Microsoft is not willing to sign currently.
Ah, so transitioning to GCC 5 is blocked by Mircosoft? Nice.
Richard.
On Thu, 9 Apr 2015, Richard Biener wrote:
On Thu, 9 Apr 2015, Marcus Meissner wrote:
On Thu, Apr 09, 2015 at 10:50:07AM +0200, Richard Biener wrote:
On Tue, 24 Mar 2015, Richard Biener wrote:
The project to get packages to build with GCC 5 which we should try to transition to has progressed but is not yet finished.
https://build.opensuse.org/project/show/openSUSE:Factory:Staging:Gcc49
currently shows 13 package build fails and 59 packages not built due to failed requirements.
Of the packages that fail building some of them have patches from me either in SR state or just in the devel projects which have not been pushed to Factory.
So we are down to a handful of fails and -><- this close from building DVD images. Main offenders that prevent that are
shim -- fixed in devel project but not forwarded to factory :( yast2-auth-server, C++ error, fix sent to maintainers open-lldp -- fixed in devel project but not forwarded to factory :(
some fixes are now finally staged and should appear in factory soon (hopefully).
Please push your packages to factory.
shim might be tricky, this might be the one Microsoft is not willing to sign currently.
Ah, so transitioning to GCC 5 is blocked by Mircosoft? Nice.
Btw, if that is really the case we shouldn't re-build shim all the time. Any minor GCC change can cause different code to be generated and thus require re-signing (or even some random changes in headers).
Richard.
On Thu, Apr 09, 2015 at 11:11:10AM +0200, Richard Biener wrote:
Btw, if that is really the case we shouldn't re-build shim all the time. Any minor GCC change can cause different code to be generated and thus require re-signing (or even some random changes in headers).
We will have to change the way we package shim anyway because of new requirements by Microsoft. I already talked to some people about that, but I will have to wait until next week when Stephan Behlert is back from FTO until we can decide this.
Johannes
On Thu, Apr 9, 2015 at 6:05 AM, Richard Biener rguenther@suse.de wrote:
some fixes are now finally staged and should appear in factory soon (hopefully).
Please push your packages to factory.
shim might be tricky, this might be the one Microsoft is not willing to sign currently.
Ah, so transitioning to GCC 5 is blocked by Mircosoft? Nice.
I already fixed the package itself..the signing policies/politics is a different can of worms.
-
Cristian Rodríguez -
Johannes Segitz -
Marcus Meissner -
Michael Andres -
Olaf Hering -
Richard Biener -
Simon -
Stephan Kulow