[FFmpeg-devel] Debug builds and if (ARCH_...) linking issues

[Rostislav Pehlivanov]

On 13 April 2017 at 16:51, wm4 <nfxjfg at googlemail.com> wrote:

> On Thu, 13 Apr 2017 17:39:57 +1000
> Matt Oliver <protogonoi at gmail.com> wrote:
>
> > On 13 April 2017 at 17:20, Aaron Levinson <alevinsn at aracnet.com> wrote:
> >
> > > I wanted to build a debug build of ffmpeg using Visual C++ today, one
> > > without any optimizations.  This implies the use of the -Od compiler
> > > option.  Unfortunately, I quickly discovered that the build fails soon
> > > after it starts because it can't find certain architecture-specific
> > > references.  For example, in libavutil/cpu.c, there is the following:
> > >
> > >     if (ARCH_AARCH64)
> > >         return ff_get_cpu_flags_aarch64();
> > >
> > > The linker couldn't find ff_get_cpu_flags_aarch64 (and other similar
> > > references) and failed.  This isn't an issue when optimizations are
> turned
> > > on because the compiler notices that ARCH_AARCH64 is defined as 0 and
> > > eliminates the relevant code.
> > >
> > > Effectively, successful builds of ffmpeg depend on this compiler
> > > optimization.  This appears to have been the standard practice in the
> > > ffmpeg code base for at least the last few years, but it is unclear to
> me
> > > why this approach is being used, since, in addition to depending on
> > > specific compiler behavior, it prevents fully debug builds from
> succeeding,
> > > at least with Visual C++.
> > >
> > > If people like the if (ARCH_...) syntax, while it wouldn't look quite
> as
> > > nice, what's wrong with doing the following:
> > >
> > > #if ARCH_AARCH64
> > >     if (ARCH_AARCH64)
> > >         return ff_get_cpu_flags_aarch64();
> > > #endif
> > >
> > > Another, much less desirable option is to use #pragma optimize for the
> > > relevant functions in ffmpeg to turn optimizations on for specific
> > > functions.
> > >
> > > A third option would be to build only the relevant files with
> > > optimizations turned on, but this will end up making the Makefiles more
> > > complicated, and the relative simplicity of the Makefiles is appealing.
> > >
> > > For now, I'm using both -Od and -Og with Visual C++ (-Og turns on some
> > > optimizations, but not as much as -O1 or -O2), but this isn't the same
> as a
> > > true debug build.
> > >
> >
> > Similar patches have been submitted before. This is an issue with Dead
> Code
> > Elimination (DCE) within FFmpeg and the fact the MSVC doesn't support
> > removing it in debug builds.
> >
> > There have been some discussions on the mailing list in the past about
> > resolving this but nothing was ever decided.
> >
> > As a quick and dirty work around I have a tool that i wrote that scans in
> > the configure/makefile from a ffmpeg distro and generates a native Visual
> > Studio project file that can be used to just compile within Visual Studio
> > itself. You just pass it the desired configure options that you want to
> use
> > to build the project and it will make one for you. The main thing is that
> > it scans the source and automatically generates the missing DCE sections
> > and adds them so that everything will compile correctly with Debug builds
> > and you can debug directly in VS. You can find the tool here
> > http://shiftmediaproject.github.io/1-projects/ (normally i wouldn't put
> > external references on the mailing list but this may be of use to you).
>
> Any chance you could revive your old patches to remove the DCE
> requirement? (Not sure if there were any patches.)
>
> Before you do any real work, make a thread on the ML requesting
> comments on this. Although I would very much welcome such patches, I'm
> not fully sure about others.
>
> This DCE requirement is pretty painful, and affects debugging on Linux
> as well.
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

CCing him because its been 4 months

btw how would the GCC pragma approach work?