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

[Måns Rullgård]

Ramiro Polla <ramiro.polla at gmail.com> writes:

> 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.
>
> Ramiro Polla
>
> Index: configure
> ===================================================================
> --- configure	(revision 18499)
> +++ configure	(working copy)
> @@ -1634,6 +1634,7 @@
>          SHFLAGS='-shared -Wl,--output-def,$$(@:$(SLIBSUF)=.def) -Wl,--out-implib,$(SUBDIR)lib$(SLIBNAME:$(SLIBSUF)=.dll.a) -Wl,--enable-runtime-pseudo-reloc -Wl,--enable-auto-image-base'
>          objformat="win32"
>          enable dos_paths
> +        check_cflags -fno-common
>          if ! enabled x86_64; then
>              check_cpp_condition _mingw.h "(__MINGW32_MAJOR_VERSION > 3) || (__MINGW32_MAJOR_VERSION == 3 && __MINGW32_MINOR_VERSION >= 15)" ||
>                  die "ERROR: MinGW runtime version must be >= 3.15."
> @@ -1652,6 +1653,7 @@
>          SHFLAGS='-shared -Wl,--enable-auto-image-base'
>          objformat="win32"
>          enable dos_paths
> +        check_cflags -fno-common
>          ;;
>      *-dos|freedos|opendos)
>          disable ffplay ffserver
> @@ -1659,6 +1661,7 @@
>          network_extralibs="-lsocket"
>          objformat="coff"
>          enable dos_paths
> +        check_cflags -fno-common
>          ;;
>      linux)
>          enable dv1394

OK

-- 
M?ns Rullg?rd
mans at mansr.com