On Fri, Dec 16, 2016 at 1:34 AM, Matt Oliver <protogo...@gmail.com> wrote: > On 16 December 2016 at 11:20, Carl Eugen Hoyos <ceffm...@gmail.com> wrote: > >> 2016-12-14 16:47 GMT+01:00 Steve Lhomme <rob...@gmail.com>: >> > From: Steve Lhomme <rob...@gmail.com> >> > >> > Without any optimization flags, MSVC does no dead code elimination (DCE) >> at >> > all, even for the most trivial cases. DCE is a prerequisite for building >> ffmpeg >> > correctly, otherwise there are undefined references to functions for >> other >> > architectures and disabled components. >> > >> > -Os -Og is the minimal optimization flags for MSVC that does include DCE. >> >> The patch looks good to me if -Og alone doesn't help, >> thank you for the improved commit message. > > > Im not sure this is a good idea. It doesnt seem right to me that if the > user selects to disable optimizations that configure still performs some > anyway. As far as I see it if the user selects to have no optimizations > then there should be no optimizations. This seems like a slightly incorrect > hack to get around ffmpeg using DCE as opposed to tackling the broader > issue of DCE breaking builds, and not just with msvc and not just with no > optimizations enabled. > > As a slightly more appropriate (although still hacky fix) you can instead > add /FORCE:UNRESOLVED to the linker command which will still result in a > large number off errors being generated however they will be ignored and an > output binary will still be generated. As the errors all relate to > functions that never get called the output binary is still perfectly > functional and i think importantly doesnt contain optimizations just as the > user requested. Also this fixes debug builds aswell.
It seems it's linking loosely, meaning it may not see if some actualmissing call exists or not. I just tried it and it segfaults if calling a function that doesn't exist. > I still think the best solution would be to apply a broader ranging fix to > the use of DCE but until a consensus is made on that then the above may be > of some help. I agree. > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
