[FFmpeg-devel] [PATCH] configure: fix linking with MSVC when using --disable-optimizations

[Stève Lhomme]

On Fri, Dec 16, 2016 at 1:34 AM, Matt Oliver <protogonoi at gmail.com> wrote:
> On 16 December 2016 at 11:20, Carl Eugen Hoyos <ceffmpeg at gmail.com> wrote:
>
>> 2016-12-14 16:47 GMT+01:00 Steve Lhomme <robux4 at gmail.com>:
>> > From: Steve Lhomme <robux4 at 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 at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel