[FFmpeg-devel] [PATCH] Add -fno-common to PE32 CFLAGS

[Baptiste Coudurier]

Hi Ramiro,

On 4/13/2009 2:12 PM, Ramiro Polla wrote:
> Hi,
> 
> On Mon, Apr 13, 2009 at 5:31 PM, Baptiste Coudurier
> <baptiste.coudurier at gmail.com> wrote:
>> On 4/13/2009 12:48 PM, Baptiste Coudurier wrote:
>>> On 4/8/2009 6:42 PM, Ramiro Polla wrote:
>>>> Some time ago Art Clarke sent a patch to unconditionally add
>>>> -fno-common to mingw32 builds because of a bug in GCC. Instead of
>>>> applying the patch, the documentation was updated to reflect this bug
>>>> and the workaround.
>>>>
>>>> The bug details can be found here:
>>>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37216
>>>>
>>>> I finally took some time to investigate what combination of
>>>> gcc+binutils triggers the bug. Just like Brian Dessent mentions in
>>>> comment #6, the bug appears with binutils starting November 2007. The
>>>> gcc version doesn't matter as long as it puts data in .comm. binutils
>>>> 2.18 doesn't show this bug, but it has other shortcomings which make
>>>> it not fit for building FFmpeg.
>>>>
>>>> With current mingw32 binutils floating around the web, all builds will
>>>> crash at some point in some optimizations (maybe Baptiste can give us
>>>> a sample that really crashes, I haven't seen them yet, but there are
>>>> lots of reports).
>>>>
>>>> So is it ok to unconditionally include this flag with attached patch
>>>> (and a very descriptive log message) before binutils is fixed?
>>> Yes, please many bug reports on windows because of this, shared libs are
>>> just broken without it.
>>>
>>> You might remove it for OS/2 though according to Dave Yeo.
>> I think you could also only add it for shared libs. I don't recall it
>> was needed for static builds.
> 
> The bug on gcc+binutils shows itself independent of being in a .dll or
> in the .exe itself, so I assume this bug doesn't appear on static
> FFmpeg builds purely by luck.
> 
> I updated the patch removing the flag from OS/2 as suggested by Dave Yeo.
> 
> The commit message would be:
> "win32, dos: Work around a bug in the GNU toolchain.
> The bug[1] is exposed when gcc decides to put some data in a common
> section (i.e. data that will be used by more than one object). It will
> suggest the data to be aligned, but binutils >= 2.19 will fail to
> properly align it. Thus if the data requires any alignment greater
> than 4, the application will crash.
> The workaround prevents gcc from putting data in a common section,
> instead putting it in a properly aligned section.
> 
> [1] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37216"
> 
> I'll commit this if I get an explicit ok from the build system
> maintainers, because I don't want them bugging us later on if they
> don't like this hack. And if they're not ok with it, then please
> suggest an alternative solution.
> 

Well, ok then, I'm for it. It could also be applied to the 0.5 branch.
Any objection ?

-- 
Baptiste COUDURIER                              GnuPG Key Id: 0x5C1ABAAA
Key fingerprint                 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
checking for life_signs in -lkenny... no
FFmpeg maintainer                                  http://www.ffmpeg.org