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

[Jarod Wilson]

Jakub Jelinek wrote:
> On Tue, Feb 03, 2009 at 03:39:29PM -0500, Orcan Ogetbil wrote:
>> On Tue, Feb 3, 2009 at 2:59 PM, Jakub Jelinek  wrote:
>>> On Tue, Feb 03, 2009 at 08:52:53PM +0100, Julian Sikorski wrote:
>>>> 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.
>>> There is a whole bunch of errors about undefined __sync_fetch_and_add_4
>>> from what I can see.  These are the same reason as has been discussed
>>> before, this libstdc++ header requires -march=i486 or later (the default
>>> is -march=i586, but i386.rpm builds use explicit -march=i386).
>>> Koji will be hopefully changed soon to default to i586.rpm or i686.rpm.
>>>
>>>        Jakub
>> Do we need to "fix" these flags in the SPEC file, or shall we wait
>> until koji is "fixed"?
> 
> Wait, please don't change SPEC files for this.  I'm going to surround
> _GLIBCXX_ATOMIC_BUILTINS_N defines in c++config.h with
> #ifdef __GCC_HAVE_SYNC_COMPARE_AND_SWAP_N guards in 4.4.0-0.14, which
> should allow even building of -march=i386 stuff against that libstdc++.

I've fixed up both dvgrab and ivtv-utils and sent appropriate patches 
upstream, but I'm slightly clueless what's going on with libdv...

http://sunsite.mff.cuni.cz/rawhide20090126-gcc44/fails-even-with-43/libdv-1.0.0-5.fc10.src.rpm/build.log

Looks to be fall-out specific to the new libtool in rawhide. Karsten, 
any clues?

--jarod