Results of a test mass rebuild of rawhide-20090126 with gcc-4.4.0-0.9

[Jon Ciesla]

Is it anticipated that there will be a rash of FTBFS bugs for packages
that still fail X days after gcc-4.4 hits rawhide?

I think I got all mine, but would appreciate the extra nagging if I didn't.

> Hi!
>
> In the past few days I've done a mass rebuild of rawhide-20090126
> in mock with gcc-4.4.0-0.9 (and corresponding libtool).
> 6228 packages were successfully built, for the rest I've tried
> to rebuild them also with gcc-4.3.2-7 (though I ran out of time,
> so a couple of packages weren't attempted with 4.3).
>
> Here are the most common causes of the regressions (fails to build
> with gcc-4.4.0-0.9, succeeds with gcc-4.3.2-7):
>
> - 142 failures
>   C++ <string> (<bits/char_traits.h>) no longer includes <cstdio>.
>   So does <ios>, <streambuf>, <iomanip>, <locale>.
>   When you need anything from C stdio.h, such as EOF, *printf*,
>   *scanf*, remove etc., add #include <cstdio> to all sources that
>   need it.
>   http://sunsite.mff.cuni.cz/rawhide20090126-gcc44/cstdio/
>
> - 22 failures
>   G++ 4.4 rejects int main () { return main (); } or
>   int main () { main (); return 0; },
>   as main shouldn't be used within the program (see ISO C++
> [basic.start.main]/3).
>   This breaks some configure scripts, e.g. AC_CHECK_LIB with second
> argument main as in
>   AC_CHECK_LIB(stdc++,main,,AC_MSG_ERROR([libstdc++ not installed]))
>   will now fail.  As AC_CHECK_LIB isn't well suited for C++, which
> requires
>   prototypes and AC_CHECK_LIB doesn't provide them, I guess
>   AC_CHECK_LIB(stdc++,int,,AC_MSG_ERROR([libstdc|| not installed]))
>   could be used instead.  This results in int main () { return int (); }
>   or int main () { int (); return 0; }
>   Only packages that actually failed to build because of this
>   are listed, there are many more that are affected by it though.
>   Look for checking for main in -l... giving no, even for packages
>   that succeeded.
>   http://sunsite.mff.cuni.cz/rawhide20090126-gcc44/main/
>
> - 15 failures
>   C++ <string> (<bits/postypes.h>) no longer includes <stdint.h>.
>   Neither does <ios>.  When you need uint32_t, uint8_t etc.,
>   #include <stdint.h>.
>   http://sunsite.mff.cuni.cz/rawhide20090126-gcc44/stdint/
>
> - 15 failures
>   #elif argument is now evaluated even if earlier #if/#elif
>   condition evaluated non-zero, to make sure they are valid
>   constant expressions.  See http://gcc.gnu.org/PR36320
>   To fix this, either use #else when you want it instead of
>   #elif (e.g. several packages use #elif without any argument
>   at all), or use #else #if ... #endif.
>   http://sunsite.mff.cuni.cz/rawhide20090126-gcc44/elif/
>
> - 8 failures
>   glib2's gthread.h contains a couple of aliasing issues (e.g.
>   in g_once_init_enter) and a bunch of programs get bitten by it
>   when they inline it.
>   This should be fixed in glib2.
>   http://sunsite.mff.cuni.cz/rawhide20090126-gcc44/glib.aliasing/
>
> - 6 failures
>   Other aliasing problem.  In the GCC 4.3 -> 4.4 transition
>   the most common problem is:
>   char buf[NNN];	// or unsigned char or signed char
>   ...
>   ((struct somestruct *)buf)->somefield = 1
>   While you can access any object through char, unsigned char or
>   signed char pointer and modify parts/all of it, it is not the
>   other way around.  In this case you probably want a union of
>   the buffer and struct somestruct.
>   http://sunsite.mff.cuni.cz/rawhide20090126-gcc44/aliasing/
>
> - 2 failures
>   GCC bugs that were already fixed in newer gcc 4.4 (4.4.0-0.13
>   should work).
>   http://sunsite.mff.cuni.cz/rawhide20090126-gcc44/already_fixed/
>
> - 1 failure
>   Package built with -Werror, where one extra warning appeared.
>   http://sunsite.mff.cuni.cz/rawhide20090126-gcc44/Werror/
>
> - 1 failure
>   g++ now errors on:
>   struct C { virtual ~C (); };
>   struct B : public C { int i; };
>   struct A { const B a; A () { bar (&a); } void bar (const B *); };
>   while previously it only errored if C virtual wasn't involved.
>   http://sunsite.mff.cuni.cz/rawhide20090126-gcc44/uninit/
>
> - 1 failure
>   __builtin_stdarg_start has been removed.  #include <stdarg.h>
>   should be used, rather than writing stuff by hand, and if really
> necessary
>   (why?), then at least it needs to use __builtin_va_start instead.
>   http://sunsite.mff.cuni.cz/rawhide20090126-gcc44/stdarg/
>
> - 1 failure
>   open with O_CREAT set in the second argument needs to have 3 arguments,
> not
>   just 2.
>   http://sunsite.mff.cuni.cz/rawhide20090126-gcc44/open2/
>
> - 1 failure
>   free called with a pointer to non-heap allocated object.
>   E.g.
>   char buf[128], *bufp;
>   ...
>   bufp = buf;
>   if (something)
>   {
>     bufp = malloc (somesize);
>   ...
>   }
>   ...
>   if (bufp != buf)
>     free (buf);  // Should have been bufp.
>   http://sunsite.mff.cuni.cz/rawhide20090126-gcc44/nonheapfree/
>
> - 30 failures
>   Unsorted stuff that succeeds to build with 4.3 and fails to build
>   with 4.4.  Only looked briefly at openbabel, in which case
>   the bug is that it has locale.h in the include search path, which
>   overrides the system <locale.h>.
>   http://sunsite.mff.cuni.cz/rawhide20090126-gcc44/unsorted/
>
> - 31 failures
>   Various mock related issues, packages failed at root.log stage,
>   before starting to build.  Some might be related to mock being used
>   on RHEL5 instead of a recent fedora.
>   http://sunsite.mff.cuni.cz/rawhide20090126-gcc44/deps/
>
> - 167 failures
>   packages that failed to build both with gcc 4.3 and 4.4
>   http://sunsite.mff.cuni.cz/rawhide20090126-gcc44/fails-even-with-43/
>
> - 117 failures
>   unanalyzed packages with failed to build with 4.4, but 4.3 build wasn't
>   performed (ran out of time), so either they fall into fails-even-with-43
>   category, or into unsorted.
>
> 	Jakub
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>


-- 
in your fear, speak only peace
in your fear, seek only love

-d. bowie