RPMFusion buildsystem is setting wrongs CFLAGS while building packages at %configure step

[Thorsten Leemhuis]

On 24.07.2008 17:31, Michael Schwendt wrote:
> On Thu, 24 Jul 2008 15:50:27 +0200, Thorsten Leemhuis wrote:
> 
>> On 24.07.2008 15:04, KH KH wrote:
>>> Each package that is currently build (either in F-9 F-8 or devel
>>> repository) have it CFLAGS set incorrectly at build time
>>> In most case, that was caused by the %configure macro to be set incorrectly.
>>>
>>> I don't know what happen here, but since it still work with the
>>> current set of Fedora package while using mock
>>> i would say something in the buildsys have been set incorrectly...
>> Seems correct, but I can't see any obvious reasons why it's happening 
>> (the mock config files are nearly identical with the ones from Livna 
>> (different repos of course); the buildsys is the same; but it works for 
>> livna builds, but not for RPM Fusion builds).
>>
>> I need more time to look into that. Until then I suggest we stop 
>> building more RPMS for RPM Fusion, as all noarch packages likely need 
>> another rebuild.
> 
> A bad buildsys-build pkg?
> Above can happen if  redhat-rpm-config  is not installed into
> the buildroot. redhat-rpm-config is where %optflags and
> %global_cflags are defined.

Yeah, that was the problem. Fixed now:

http://buildsys.rpmfusion.org/logs/fedora-9-rpmfusion_free/182-faac-1.25-5.fc9/i386/build.log

> + CFLAGS='-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i386 -mtune=generic -fasynchronous-unwind-tables'
> + export CFLAGS
> + CXXFLAGS='-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i386 -mtune=generic -fasynchronous-unwind-tables'
> + export CXXFLAGS
> + FFLAGS='-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i386 -mtune=generic -fasynchronous-unwind-tables'
> + export FFLAGS

Many thx Michael.

/me slaps himself for doing a stupid change (that caused this problem) 
two weeks ago to fix something else

I'll queue rebuilds for the existing packages over the next few days. 
But I don't mind if the maintainer do it themselves. ;-)

CU
knurd