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. > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel >
CCing him because its been 4 months btw how would the GCC pragma approach work? _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
