Re: Results of a test mass rebuild of rawhide/x86_64 with gcc-5.0.0-0.5.fc22
On Thu, Feb 19, 2015 at 04:12:43PM +0100, Frantisek Kluknavsky wrote: > a list of things that usually break with each new gcc (like fortran modules) > would be nice to avoid a lot of pain with debugging. Does it already exist? > > WxGTK keeps a string WX_BUILD_OPTIONS_SIGNATURE currently saying "2.8 (no > debug,Unicode,compiler with C++ ABI 1002,wx containers,compatible with > 2.4,compatible with 2.6)" and it is checked at runtime. C++ ABI is supposed > to be unchanged in Fedora 22. This string changed anyway because > __GXX_ABI_VERSION in gcc changed. Is this expected/correct? Each freshly > rebuilt wx application will crash now. After wxGTK is rebuilt, each old > application will crash. A provenpackager should probably step in. That is a WxGTK bug. __GXX_ABI_VERSION can change, but usually the result is still ABI compatible, g++ emits just some aliases when mangling has changed. Jakub -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Results of a test mass rebuild of rawhide/x86_64 with gcc-5.0.0-0.5.fc22
Hi, a list of things that usually break with each new gcc (like fortran modules) would be nice to avoid a lot of pain with debugging. Does it already exist? WxGTK keeps a string WX_BUILD_OPTIONS_SIGNATURE currently saying "2.8 (no debug,Unicode,compiler with C++ ABI 1002,wx containers,compatible with 2.4,compatible with 2.6)" and it is checked at runtime. C++ ABI is supposed to be unchanged in Fedora 22. This string changed anyway because __GXX_ABI_VERSION in gcc changed. Is this expected/correct? Each freshly rebuilt wx application will crash now. After wxGTK is rebuilt, each old application will crash. A provenpackager should probably step in. Have a nice day, Fero -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Results of a test mass rebuild of rawhide/x86_64 with gcc-5.0.0-0.5.fc22
On Sun, Feb 8, 2015 at 10:17 AM, Marek Polacek wrote: > odb-2.3.0-8.fc22.src.rpm > build failure because the gcc plugin API has changed. > odb has been updated to 2.4.0 which supports the new gcc 5.0 plugin API, but whenever I try to do the rebuild it fails to find libcutl (which I rebuilt last night): http://koji.fedoraproject.org/koji/taskinfo?taskID=8966447 Any ideas on what is going on there? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Results of a test mass rebuild of rawhide/x86_64 with gcc-5.0.0-0.5.fc22
On Sun, 15 Feb 2015 23:14:33 +0100, Jakub Jelinek wrote: > On Sun, Feb 15, 2015 at 11:08:55PM +0100, Michael Schwendt wrote: > > On Sun, 8 Feb 2015 18:17:56 +0100, Marek Polacek wrote: > > > > > either package bugs, or GCC bugs. As things stand, just about 19 > > > packages did > > > not build due to bugs in gcc-5.0.0-0.5.fc22. All GCC bugs except one are > > > fixed > > > at this time, and I promise I will fix the remaining one before long. > > > > gcc-5.0.0-0.13.fc23 fails for Audacious 3.6-beta1 as tried in Copr: > > > > https://copr.fedoraproject.org/coprs/mschwendt/audacious-next/build/72152/ > > > > As I haven't had a chance to look into it, Audacious upstream believes > > it to be a C++ bug in GCC. > > File a bugreport with preprocessed source? For that I would need a Rawhide installation and time to look into it and the constexpr C++14 changes in GCC 5. The same src.rpm builds fine on Fedora 21 (and also with Clang), so for a constexpr expert it would be much easier to draw conclusions. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Results of a test mass rebuild of rawhide/x86_64 with gcc-5.0.0-0.5.fc22
On Sun, Feb 15, 2015 at 11:08:55PM +0100, Michael Schwendt wrote: > On Sun, 8 Feb 2015 18:17:56 +0100, Marek Polacek wrote: > > > either package bugs, or GCC bugs. As things stand, just about 19 packages > > did > > not build due to bugs in gcc-5.0.0-0.5.fc22. All GCC bugs except one are > > fixed > > at this time, and I promise I will fix the remaining one before long. > > gcc-5.0.0-0.13.fc23 fails for Audacious 3.6-beta1 as tried in Copr: > > https://copr.fedoraproject.org/coprs/mschwendt/audacious-next/build/72152/ > > As I haven't had a chance to look into it, Audacious upstream believes > it to be a C++ bug in GCC. File a bugreport with preprocessed source? Jakub -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Results of a test mass rebuild of rawhide/x86_64 with gcc-5.0.0-0.5.fc22
On Sun, 8 Feb 2015 18:17:56 +0100, Marek Polacek wrote: > either package bugs, or GCC bugs. As things stand, just about 19 packages did > not build due to bugs in gcc-5.0.0-0.5.fc22. All GCC bugs except one are > fixed > at this time, and I promise I will fix the remaining one before long. gcc-5.0.0-0.13.fc23 fails for Audacious 3.6-beta1 as tried in Copr: https://copr.fedoraproject.org/coprs/mschwendt/audacious-next/build/72152/ As I haven't had a chance to look into it, Audacious upstream believes it to be a C++ bug in GCC. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Results of a test mass rebuild of rawhide/x86_64 with gcc-5.0.0-0.5.fc22
Marek Polacek writes: > To get some sense on how is GCC 5 standing, we (myself and Jakub > Jelinek) have performed a test mass rebuild of rawhide (January 15th > package list) using gcc-5.0.0-0.5.fc22 on x86_64 [...] I'd like to bring to folks' attention one other scenario that can bite with a gcc major version update. It's a more subtle failure, and it might be widespread. In the case of pcp [1], it lets a build succeed, but an opaque runtime error results. In this case, the root cause was an autoconf fragment is used to detect whether gcc supports -rdynamic: catconftest.out test -s conftest.out || rdynamic_flag=-rdynamic This used to succeed under gcc 4.9, but gcc 5 emits a warning conftest.c:1:1: warning: return type defaults to `int' [-Wimplicit-int] [...] which the test takes as a failure due to its scanning of stderr. That in turn nukes use of -rdynamic, which breaks -run-time- dlopen() attempts between shared libraries. Admittedly, it's not a great test (and we're fixing it upstream). But it's possible that other programs' configury is similarly sensitive to gcc warn-by-default changes, and result in a differently configured build or even a broken runtime. [1] https://kojipkgs.fedoraproject.org//packages/pcp/3.10.3/0.508.g8090873.fc22/data/logs/x86_64/build.log , search for -rdynamic - FChE -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Results of a test mass rebuild of rawhide/x86_64 with gcc-5.0.0-0.5.fc22
On Sunday, 08 February 2015 at 18:17, Marek Polacek wrote: [...] > The following is a more detailed list of what and why failed. > abook-0.6.0-0.15.20140116git5840fce.fc22.src.rpm Fixed. Regards, Dominik -- Fedora http://fedoraproject.org/wiki/User:Rathann RPMFusion http://rpmfusion.org "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Results of a test mass rebuild of rawhide/x86_64 with gcc-5.0.0-0.5.fc22
On Sun, 08 Feb 2015 18:17:56 +0100, Marek Polacek wrote: > gdb-7.8.50.20150108-1.fc22.src.rpm Fixed/rebuilt, upstream not really affected. http://pkgs.fedoraproject.org/cgit/gdb.git/commit/?id=5d84d7a16acc0469b6829f276987cf74e10ae848 Jan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Results of a test mass rebuild of rawhide/x86_64 with gcc-5.0.0-0.5.fc22
On 02/11/2015 03:11 PM, Marek Polacek wrote: On Wed, Feb 11, 2015 at 02:58:25PM +0100, Jakub Jelen wrote: On 02/08/2015 06:17 PM, Marek Polacek wrote: To get some sense on how is GCC 5 standing, we (myself and Jakub Jelinek) have performed a test mass rebuild of rawhide (January 15th package list) using gcc-5.0.0-0.5.fc22 on x86_64, and for those packages that failed also rebuilt the same package with gcc-4.9.2-5.fc22.x86_64 to quickly remove from the list packages that fail for non-GCC related reasons. Looks like there are some new issues with gcc > 5.0.0-0.5.fc22 - my package got through your rebuild (or was not mention in list), but I see failures now in Koji or VM with gcc-5.0.0-0.10.fc22.x86_64 (koji) and gcc-5.0.0-0.9.fc22.x86_64 (virtual machine). Can somebody have a look at this issue (yes, this is update, but it fails even with last git revision on fedorahosted which worked well with gcc-4.9.2-5.fc22.x86_64 [1])? I wonder if there will be more people with such problems. Error message [2]: /usr/bin/ld: ../libssh.a(sshkey.o): relocation R_X86_64_PC32 against undefined symbol `stderr@@GLIBC_2.2.5' can not be used when making a shared object; recompile with -fPIC Indeed, it looks like openssh passed with 5.0.0-0.5.fc22; unfortunately I don't have the logs of the passed packages anymore. I'd firstly take a look into diff between config.log with 4.9 and 5; it sounds like some -fpic detection configure routine failed. Maybe it passed the rebuild only by luck (?). Marek The only difference in configure (except some switched lines) in gcc 5.* for these side configures missing: -Wsign-compare -Wno-pointer-sign Configure of ssh is the same (except the gcc version). Even the error message looks quite strange - everything is build with -fPIC. I don't think it was luck. Now the fail is quite deterministic. Jakub -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Results of a test mass rebuild of rawhide/x86_64 with gcc-5.0.0-0.5.fc22
On Wed, Feb 11, 2015 at 02:58:25PM +0100, Jakub Jelen wrote: > On 02/08/2015 06:17 PM, Marek Polacek wrote: > >To get some sense on how is GCC 5 standing, we (myself and Jakub Jelinek) > >have performed a test mass rebuild of rawhide (January 15th package list) > >using gcc-5.0.0-0.5.fc22 on x86_64, and for those packages that failed also > >rebuilt the same package with gcc-4.9.2-5.fc22.x86_64 to quickly remove from > >the list packages that fail for non-GCC related reasons. > Looks like there are some new issues with gcc > 5.0.0-0.5.fc22 - my package > got through your rebuild (or was not mention in list), but I see failures > now in Koji or VM with gcc-5.0.0-0.10.fc22.x86_64 (koji) and > gcc-5.0.0-0.9.fc22.x86_64 (virtual machine). > > Can somebody have a look at this issue (yes, this is update, but it fails > even with last git revision on fedorahosted which worked well with > gcc-4.9.2-5.fc22.x86_64 [1])? I wonder if there will be more people with > such problems. > > Error message [2]: > /usr/bin/ld: ../libssh.a(sshkey.o): relocation R_X86_64_PC32 against > undefined symbol `stderr@@GLIBC_2.2.5' can not be used when making a shared > object; recompile with -fPIC Indeed, it looks like openssh passed with 5.0.0-0.5.fc22; unfortunately I don't have the logs of the passed packages anymore. I'd firstly take a look into diff between config.log with 4.9 and 5; it sounds like some -fpic detection configure routine failed. Maybe it passed the rebuild only by luck (?). Marek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Results of a test mass rebuild of rawhide/x86_64 with gcc-5.0.0-0.5.fc22
On 02/08/2015 06:17 PM, Marek Polacek wrote: To get some sense on how is GCC 5 standing, we (myself and Jakub Jelinek) have performed a test mass rebuild of rawhide (January 15th package list) using gcc-5.0.0-0.5.fc22 on x86_64, and for those packages that failed also rebuilt the same package with gcc-4.9.2-5.fc22.x86_64 to quickly remove from the list packages that fail for non-GCC related reasons. Looks like there are some new issues with gcc > 5.0.0-0.5.fc22 - my package got through your rebuild (or was not mention in list), but I see failures now in Koji or VM with gcc-5.0.0-0.10.fc22.x86_64 (koji) and gcc-5.0.0-0.9.fc22.x86_64 (virtual machine). Can somebody have a look at this issue (yes, this is update, but it fails even with last git revision on fedorahosted which worked well with gcc-4.9.2-5.fc22.x86_64 [1])? I wonder if there will be more people with such problems. Error message [2]: /usr/bin/ld: ../libssh.a(sshkey.o): relocation R_X86_64_PC32 against undefined symbol `stderr@@GLIBC_2.2.5' can not be used when making a shared object; recompile with -fPIC Best Regards, Jakub [1] Successful build: http://koji.fedoraproject.org/koji/buildinfo?buildID=606983 [2] Failed build: http://koji.fedoraproject.org/koji/taskinfo?taskID=8894851 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Results of a test mass rebuild of rawhide/x86_64 with gcc-5.0.0-0.5.fc22
On Sun, Feb 08, 2015 at 06:17:56PM +0100, Marek Polacek wrote: > libixion-0.7.0-3.fc22.src.rpm > liborcus-0.7.0-5.fc22.src.rpm Fixed. D, -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Results of a test mass rebuild of rawhide/x86_64 with gcc-5.0.0-0.5.fc22
- Original Message - > From: "Jakub Jelinek" > To: "Development discussions related to Fedora" > > Cc: "Marek Polacek" > Sent: Wednesday, February 11, 2015 12:53:18 PM > Subject: Re: Results of a test mass rebuild of rawhide/x86_64 with > gcc-5.0.0-0.5.fc22 > > On Wed, Feb 11, 2015 at 06:25:10AM -0500, Matej Stuchlik wrote: > > > python3-3.4.2-3.fc22.src.rpm > > > build started failing with http://gcc.gnu.org/PR60517 > > > The code has an undefined behavior (returning address of a local > > > variable); > > > it > > > tried to perform a stack overflow, but the compiler turned the code via > > > tail > > > recursion > > > optimization into an endless loop. > > > > Would you have a buildlog of the failure available somewhere? I've tried to > > rebuild it [1] > > and it seems to pass just fine. > > You've verified it rebuilt on i686. You've also got it stuck forever in > endless loop on x86_64 [1]. Ow, my bad, I assumed it would pass on x86_64 as well. Thanks for pointing that out. > > [1] http://koji.fedoraproject.org/koji/taskinfo?taskID=8893808 > > Jakub > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Results of a test mass rebuild of rawhide/x86_64 with gcc-5.0.0-0.5.fc22
On Wed, Feb 11, 2015 at 06:25:10AM -0500, Matej Stuchlik wrote: > > python3-3.4.2-3.fc22.src.rpm > > build started failing with http://gcc.gnu.org/PR60517 > > The code has an undefined behavior (returning address of a local > > variable); > > it > > tried to perform a stack overflow, but the compiler turned the code via > > tail > > recursion > > optimization into an endless loop. > > Would you have a buildlog of the failure available somewhere? I've tried to > rebuild it [1] > and it seems to pass just fine. You've verified it rebuilt on i686. You've also got it stuck forever in endless loop on x86_64 [1]. > [1] http://koji.fedoraproject.org/koji/taskinfo?taskID=8893808 Jakub -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Results of a test mass rebuild of rawhide/x86_64 with gcc-5.0.0-0.5.fc22
Marek Polacek writes: > To get some sense on how is GCC 5 standing, we (myself and Jakub Jelinek) > have performed a test mass rebuild of rawhide (January 15th package list) > using gcc-5.0.0-0.5.fc22 on x86_64, and for those packages that failed also > rebuilt the same package with gcc-4.9.2-5.fc22.x86_64 to quickly remove from > the list packages that fail for non-GCC related reasons. > ... > openldap-2.4.40-5.fc22.src.rpm Fixed: https://bugzilla.redhat.com/show_bug.cgi?id=1191098 -- Jan Synacek Software Engineer, Red Hat signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Results of a test mass rebuild of rawhide/x86_64 with gcc-5.0.0-0.5.fc22
On Wed, Feb 11, 2015 at 06:25:10AM -0500, Matej Stuchlik wrote: > > python3-3.4.2-3.fc22.src.rpm > > build started failing with http://gcc.gnu.org/PR60517 > > The code has an undefined behavior (returning address of a local > > variable); > > it > > tried to perform a stack overflow, but the compiler turned the code via > > tail > > recursion > > optimization into an endless loop. > > Would you have a buildlog of the failure available somewhere? I've tried to > rebuild it [1] > and it seems to pass just fine. You might want to look at http://bugs.python.org/issue23433, which contains more information about this issue (and even a patch). Marek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Results of a test mass rebuild of rawhide/x86_64 with gcc-5.0.0-0.5.fc22
> python3-3.4.2-3.fc22.src.rpm > build started failing with http://gcc.gnu.org/PR60517 > The code has an undefined behavior (returning address of a local > variable); > it > tried to perform a stack overflow, but the compiler turned the code via > tail > recursion > optimization into an endless loop. Would you have a buildlog of the failure available somewhere? I've tried to rebuild it [1] and it seems to pass just fine. Thanks, Matt [1] http://koji.fedoraproject.org/koji/taskinfo?taskID=8893808 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Results of a test mass rebuild of rawhide/x86_64 with gcc-5.0.0-0.5.fc22
On 2015-02-08, 17:17 GMT, Marek Polacek wrote: > xiphos-4.0.0-3.fc22.src.rpm > this package failed to build because the limit of the > instantiation depth has been reached. Upstream maintainers of Xiphos asked me whether there are some build.logs for this available as obviously they have no environment to reproduce this on their own. Matěj -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Results of a test mass rebuild of rawhide/x86_64 with gcc-5.0.0-0.5.fc22
On 02/10/2015 07:05 AM, Ralf Corsepius wrote: > Well, wouldn't you agree that developers should be able to read warnings > and filter out the serious one? If a project has more than a screen-full of "harmless" warnings, then it's very easy to miss when a serious one slips in. I prefer -Werror so that nothing gets by, all warnings must be considered. It's not that much of a burden after you first get to a warning-free build. I could see the argument that this approach belongs in upstream development, not so much distro packaging. I still think it's useful to know that any patches applied are warning-free too though. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Results of a test mass rebuild of rawhide/x86_64 with gcc-5.0.0-0.5.fc22
On Tue, Feb 10, 2015 at 04:05:31PM +0100, Ralf Corsepius wrote: > On 02/10/2015 03:56 PM, Adam Jackson wrote: > > >If only there was some way to use different CFLAGS for configure than > >for the project. > > Well, wouldn't you agree that developers should be able to read warnings and > filter out the serious one? But -Werror automates that, at the cost that when compiler changes, grows new warnings etc., you might need to adjust your code, and perhaps work around false positive warnings or individually disable them. Anyway, the problem was that K&R functions with implicit int etc. are not valid in C99 or C11, and it would be desirable if developers from time to time compared e.g. config.h files upon major compiler bumps if something important didn't get turned off. Lots of failed configure tests will show up somewhere during the build or in the testsuites, but some changes might go unnoticed. Jakub -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Results of a test mass rebuild of rawhide/x86_64 with gcc-5.0.0-0.5.fc22
On Mon, Feb 9, 2015 at 10:22 PM, Marek Polacek wrote: > IIRC bigloo contains various "autoconf" shell scripts with K&R code in > them (that fail with -Werror now) to detect e.g. -fpic. So that's why > the -fpic wasn't used. Oh, I see. Thanks. I have sent an email upstream to inform them of the nature of the problem. Regards, -- Jerry James http://www.jamezone.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Results of a test mass rebuild of rawhide/x86_64 with gcc-5.0.0-0.5.fc22
On 02/10/2015 03:56 PM, Adam Jackson wrote: If only there was some way to use different CFLAGS for configure than for the project. Well, wouldn't you agree that developers should be able to read warnings and filter out the serious one? Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Results of a test mass rebuild of rawhide/x86_64 with gcc-5.0.0-0.5.fc22
On Tue, 2015-02-10 at 07:34 +0100, Ralf Corsepius wrote: > On 02/10/2015 06:22 AM, Marek Polacek wrote: > > On Mon, Feb 09, 2015 at 02:43:25PM -0700, Jerry James wrote: > >> On Sun, Feb 8, 2015 at 10:17 AM, Marek Polacek wrote: > >>> bigloo-4.1a-6.2.fc22.src.rpm > >>> memstomp-0.1.4-15.fc22.src.rpm > >>> build failure due to gnu11 change: -Wimplicit-int is turned on > >>> by default now, > >>> which is the reason these packages didn't compile properly. See > >>> the porting_to > >>> document for more details. > >> > >> The bigloo failure had nothing to do with -Wimplicit-int. One file > >> that should have been compiled with -fPIC wasn't. I don't know why > >> this didn't cause problems before. Fixed in Rawhide. > > > > IIRC bigloo contains various "autoconf" shell scripts with K&R code in > > them (that fail with -Werror now) > > Remove these -Werrors and tell upstream to not use -Werror. > -Werror turns harmless warnings into errors. > > As autoconf scripts are based on compilers issuing errors only on real > errors and not on otherwise harmless warnings, -Werror is not useful > with autoconf scripts and is _guaranteed_ to break autoconf scripts, > because the items GCC warns about are changing with each GCC-release and > also depend on other factors (CFLAGS) in effect. If only there was some way to use different CFLAGS for configure than for the project. - ajax -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Results of a test mass rebuild of rawhide/x86_64 with gcc-5.0.0-0.5.fc22
On 02/10/2015 06:22 AM, Marek Polacek wrote: On Mon, Feb 09, 2015 at 02:43:25PM -0700, Jerry James wrote: On Sun, Feb 8, 2015 at 10:17 AM, Marek Polacek wrote: bigloo-4.1a-6.2.fc22.src.rpm memstomp-0.1.4-15.fc22.src.rpm build failure due to gnu11 change: -Wimplicit-int is turned on by default now, which is the reason these packages didn't compile properly. See the porting_to document for more details. The bigloo failure had nothing to do with -Wimplicit-int. One file that should have been compiled with -fPIC wasn't. I don't know why this didn't cause problems before. Fixed in Rawhide. IIRC bigloo contains various "autoconf" shell scripts with K&R code in them (that fail with -Werror now) Remove these -Werrors and tell upstream to not use -Werror. -Werror turns harmless warnings into errors. As autoconf scripts are based on compilers issuing errors only on real errors and not on otherwise harmless warnings, -Werror is not useful with autoconf scripts and is _guaranteed_ to break autoconf scripts, because the items GCC warns about are changing with each GCC-release and also depend on other factors (CFLAGS) in effect. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Results of a test mass rebuild of rawhide/x86_64 with gcc-5.0.0-0.5.fc22
On Mon, Feb 09, 2015 at 02:43:25PM -0700, Jerry James wrote: > On Sun, Feb 8, 2015 at 10:17 AM, Marek Polacek wrote: > > bigloo-4.1a-6.2.fc22.src.rpm > > memstomp-0.1.4-15.fc22.src.rpm > > build failure due to gnu11 change: -Wimplicit-int is turned on by > > default now, > > which is the reason these packages didn't compile properly. See > > the porting_to > > document for more details. > > The bigloo failure had nothing to do with -Wimplicit-int. One file > that should have been compiled with -fPIC wasn't. I don't know why > this didn't cause problems before. Fixed in Rawhide. IIRC bigloo contains various "autoconf" shell scripts with K&R code in them (that fail with -Werror now) to detect e.g. -fpic. So that's why the -fpic wasn't used. Marek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Results of a test mass rebuild of rawhide/x86_64 with gcc-5.0.0-0.5.fc22
On Sun, Feb 8, 2015 at 10:17 AM, Marek Polacek wrote: > bigloo-4.1a-6.2.fc22.src.rpm > memstomp-0.1.4-15.fc22.src.rpm > build failure due to gnu11 change: -Wimplicit-int is turned on by > default now, > which is the reason these packages didn't compile properly. See the > porting_to > document for more details. The bigloo failure had nothing to do with -Wimplicit-int. One file that should have been compiled with -fPIC wasn't. I don't know why this didn't cause problems before. Fixed in Rawhide. -- Jerry James http://www.jamezone.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Results of a test mass rebuild of rawhide/x86_64 with gcc-5.0.0-0.5.fc22
On Sun, Feb 08, 2015 at 06:17:56PM +0100, Marek Polacek wrote: > criu-1.4-1.fc22.src.rpm > gcc bug - rejects valid code in C99 mode ([X ... Y] style > initialization, > a GNU extension). > not fixed yet, http://gcc.gnu.org/PR64856 Fixed upstream now. Marek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Results of a test mass rebuild of rawhide/x86_64 with gcc-5.0.0-0.5.fc22
On 08/02/15 17:17, Marek Polacek wrote: nodejs-mapnik-vector-tile-0.6.1-1.fc22.src.rpm build failure due to wrong check of the GCC version; it uses C++11 features without specifying -std=c++11 or -std=gnu++11. I've patched this in Fedora and sent the patch upstream. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Results of a test mass rebuild of rawhide/x86_64 with gcc-5.0.0-0.5.fc22
To get some sense on how is GCC 5 standing, we (myself and Jakub Jelinek)
have performed a test mass rebuild of rawhide (January 15th package list)
using gcc-5.0.0-0.5.fc22 on x86_64, and for those packages that failed also
rebuilt the same package with gcc-4.9.2-5.fc22.x86_64 to quickly remove from
the list packages that fail for non-GCC related reasons.
There were 16230 packages overall. 15303 packages built fine, 691 packages
failed to build with both gcc-5.0.0-0.5.fc22 and gcc-4.9.2-5.fc22 (ignored for
this analysis, unlikely to be GCC 5 related). That leaves us with 236 packages
that failed to build with GCC 5, but succeeded with GCC 4.9. These consist of
either package bugs, or GCC bugs. As things stand, just about 19 packages did
not build due to bugs in gcc-5.0.0-0.5.fc22. All GCC bugs except one are fixed
at this time, and I promise I will fix the remaining one before long.
As usually, we will provide a "porting to" document to ease the transition to
the new GCC. This document is still in the works, yet it already contains
detailed description of the standard change for C; interested readers may visit
https://gcc.gnu.org/gcc-5/porting_to.html.
Main offender this time is probably the gnu11 change that entails different
inline semantics, enables some warnings by default, bumps the __STDC_VERSION__,
and so on. Hopefully it won't take too long till these packages catch on.
Many packages were not prepared for the new major version of GCC. There's also
been quite a lot of churn because of the preprocessor now emitting linemarkers
in the output when the -P option is not turned on. The C++ compiler now rejects
some code that it used to accept. Furthermore, GCC 5 has a batch of new
warnings,
which, combined with -Werror, caused some additional failures.
The following is a more detailed list of what and why failed.
fcoe-utils-1.0.29-7.git9267509.fc22.src.rpm
gnome-disk-utility-3.14.0-1.fc22.src.rpm
lldpad-0.9.46-8.git48a5f38.fc22.src.rpm
udisks2-2.1.3-4.fc22.src.rpm
build failure due to -Werror; the -Wformat=2 option now enables
a new warning -Wformat-signedness, which warns about e.g.:
printf ("%d\n", 1U)
(%d expects argument of type int, but the argument has type
unsigned int).
dropwatch-1.4-10.fc22.src.rpm
build failure due to gnu11 change: glibc supports dynamic
allocation for string inputs via %a modifier, but in C99,
the %a modifier is a synonym for %f (float), so the compiler
expects an argument of type float *. The package should have
used the %m modifier, specified by POSIX.1-2008.
blktap-3.0.0-2.fc22.git0.9.2.src.rpm
cdrkit-1.1.11-26.fc22.src.rpm
cstream-3.1.1-3.fc22.src.rpm
dahdi-tools-2.10.0-2.fc22.src.rpm
dee-1.2.7-3.fc22.src.rpm
gdb-7.8.50.20150108-1.fc22.src.rpm
insight-7.8.50-2.20140827git.fc22.src.rpm
libomxil-bellagio-0.9.3-10.fc22.src.rpm
lmms-1.0.3-3.fc22.src.rpm
open-vm-tools-9.4.6-4.fc22.src.rpm
perl-Crypt-OpenSSL-X509-1.803-4.fc22.src.rpm
python-pyblock-0.53-8.fc22.src.rpm
sockperf-2.5.244-2.fc22.src.rpm
build failure due to -Werror; the new
-Wlogical-not-parentheses warning included in -Wall warns
(cases such as "if (!TYPE (t) == TYPE_FOO)").
glibc-2.20.90-17.fc22.src.rpm
build failure due to -Werror; -Waggressive-loop-optimizations
triggered during the testsuite run; this has already been fixed
upstream: https://sourceware.org/ml/libc-alpha/2015-01/msg00369.html
gtranslator-2.91.6-7.fc22.src.rpm
build failure due to -Werror; -Wmissing-include-dirs warning warns;
in 4.9 and earlier, the compiler ignored the -Werror option for
this warning, now it does not.
giada-0.7.0-5.fc22.src.rpm
build failure due to -Werror; -Wparentheses triggered; this warning
now works even in g++ on e.g.:
if (!i & 4)
...
ipv6calc-0.97.4-7.fc22.src.rpm
build failure due to -Werror; the new -Wsizeof-array-argument warns.
This warning detects e.g.:
int
foo (char a[8])
{
size_t s = sizeof (a);
...
}
where sizeof on the array function parameter will return a size of
char *, not a size of the array.
xen-4.4.1-12.fc22.src.rpm
build failure due to -Werror; -Wmaybe-uninitialized warns
about possibly uninitialized fields.
thewidgetfactory-0.2.1-20.fc22.src.rpm
build failure due to gnu11 change: missing declaration of strcmp.
tog-pegasus-2.13.0-19.fc22.src.rpm
build failure due to -Werror; here -Wunused-variable triggers
(unused const Uint32 PEGASUS_DYNAMIC_LEN(PEGASUS_DYNAMIC.size());
in a header file).
mongo-cxx-driver-1.0.0-0.7.rc3.fc22.src.rpm
build failure due to -Werror; the -Wunused-variable warning triggers
rcs-5.9.3-1.fc22.src.rpm
build failure due to wrong placement of _Noreturn, with -std=gnu89
it used __attribute__((__noreturn__)) instead, which
