On 14 April 2017 at 03:31, Hendrik Leppkes <h.lepp...@gmail.com> wrote:
> On Thu, Apr 13, 2017 at 7:16 PM, Matt Oliver <protogo...@gmail.com> wrote: > > On 14 April 2017 at 02:11, Rostislav Pehlivanov <atomnu...@gmail.com> > wrote: > > > >> > >> > >> On 13 April 2017 at 16:51, wm4 <nfx...@googlemail.com> wrote: > >> > >>> On Thu, 13 Apr 2017 17:39:57 +1000 > >>> Matt Oliver <protogo...@gmail.com> wrote: > >>> > >>> > On 13 April 2017 at 17:20, Aaron Levinson <alevi...@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. > >>> > >> > > I put up a general discussion a while ago ( > > http://ffmpeg.org/pipermail/ffmpeg-devel/2016-December/204530.html) but > > there were a few people who opposed a direct removal of DCE and no one > > really came up with a consensus as to what the acceptable approach would > be. > > > > I wouldn't like any weird hacks in the source just to work-around the > lack of DCE in debug builds, so we should decide to either keep using > it or get rid of it. I agree. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
