Jakub Jelinek pisze: > 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 > I took a stab at fixing museek+, and I was able to get a bit farther. Now, I'm stuck. It says ld returned 1 exit status without an apparent reason: https://koji.fedoraproject.org/koji/getfile?taskID=1102268&name=build.log Please help. Thanks, Julian -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
