Mail Archives: cygwin/2009/07/14/12:34:57
Yaakov (Cygwin/X) wrote:
> Dave,
Hi Yaakov,
> I have been having some difficulties building the latest ffmpeg with
> gcc-4.3.2-2; the build would complete but the resulting binaries
> wouldn't launch due to the dreaded, ever-so-helpful C0000005
> initialization error. Building with gcc-3.4 worked just fine, as it has
> for some time on 1.5.
ffmpeg is one thing that's likely to suffer from the COMMON alignment
problem very badly, to the extent that I used it as a testcase when I
developed the support for the new feature, and I have a nicely working version
on my PC:
> $ ffmpeg
> FFmpeg version 0.5, Copyright (c) 2000-2009 Fabrice Bellard, et al.
> configuration: --enable-nonfree --cc=gcc-4
> libavutil 49.15. 0 / 49.15. 0
> libavcodec 52.20. 0 / 52.20. 0
> libavformat 52.31. 0 / 52.31. 0
> libavdevice 52. 1. 0 / 52. 1. 0
> built on May 30 2009 21:57:25, gcc: 4.5.0 20090528 (experimental)
> At least one output file must be specified
Without support for aligned common data it was falling down badly.
> So after rebuilding ffmpeg dozens of times (literally) to eliminate
> possible causes one-by-one, I finally found that -O2 was the cause. Odd,
> since -O2 is generally safe, and ffmpeg even adds -O3 by default. So I
> went through all the flags which -O2 turns on, and the winner (loser?)
> is -freorder-functions.
This isn't always an effective debugging technique; the -On settings don't
actually strictly correspond to combinations of the -f flags, and even when
you have tracked down an option that seems to make a difference, you don't
know whether it's actually anything to do with the optimisation that you're
tweaking, or some epiphenomenal side-effect. In this case, I suspect the
latter; changing the ordering of functions within the executable will have a
knock on effect on the order with which other symbols get dragged into the
link and the order in which commons are allocated, for example.
> Attached is a .cygport and patch which builds ffmpeg with minimal
> dependencies (libbz2 and zlib), and adds -fno-reorder-functions to
> CFLAGS (my default is "-O2 -march=i686 -pipe"), which produces working
> executables. If I remove -fno-reorder-functions, no such luck.
>
> I know it's not exactly a STC, but hopefully I've narrowed this down
> enough that you can help me figure this out.
I currently have three full gcc testruns going simultaneously and am short
of CPU cycles, so it'll be a while before I can try it. You could check if
the problem is caused by unaligned variables by either 1) seeing if adding
"-fno-common" to the CFLAGS fixes the broken executables, or 2) rebuild one
exe in both working and broken versions, adding "-Wl,-Map,..." options, and
take a look at the assignment of variables in the COMMON section to see if
something has changed in the alignments of any of them.
Of course it could be an entirely new and interesting bug. We'll see.
cheers,
DaveK
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
- Raw text -