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

[Aaron Levinson]

On 4/16/2017 8:57 AM, Matt Oliver wrote:
> On 14 April 2017 at 08:05, Hendrik Leppkes <h.leppkes at gmail.com> wrote:
>
>> On Fri, Apr 14, 2017 at 12:00 AM, Ronald S. Bultje <rsbultje at gmail.com>
>> wrote:
>>> Hi Aaron,
>>>
>>> On Thu, Apr 13, 2017 at 4:47 PM, Aaron Levinson <alevinsn at aracnet.com>
>>> wrote:
>>>
>>>> #if ARCH_AARCH64
>>>>     if (ARCH_AARCH64)
>>>>         return ff_get_cpu_flags_aarch64();
>>>> #endif
>>>>
>>>
>>> If you add #if, at least replace the if with it. #if + if is redundant.
>>>
>>>
>>>> Such a script could be reviewed and checked into the source base, then
>>>> applied to the source base, and possibly reused in the future as
>> necessary.
>>>
>>>
>>> Why not use the script as a preprocessor during compilation? We did that
>>> for pre-2013 MSVC compilation and that worked """fine""".
>>>
>>> Or why not ask Microsoft to add a CLI option to cl.exe for enabling DCE
>> but
>>> otherwise disabling optimizations? All other compilers seem capable of
>>> this, so it's odd to see that big Microsoft is incompetent whereas a
>> bunch
>>> of opensource hippies could do the same 10+ yrs ago.
>>>
>>
>> Its not a MSVC-exclusive problem. Many compilers don't perform DCE in
>> full debug builds, which are as such not possible with ffmpeg, making
>> debuging sometimes a bit annoying when a bunch of variables are
>> optimized out and stuff gets inlined.
>
>
> Unfortunately writing a script is a rather complex task as there are many
> DCE blocks that are actually generated by macro expansion and various
> pre-processor trickery (swresample is full of this sort of stuff). Combine
> that with DCE blocks being nested within each other and it becomes a rather
> complex task to find them all. Much more complex than what a simple regex
> script can handle.
>
> If people object to changing the current code base then the only solution
> would be a program/script that can generate some empty definitions for all
> the functions/variables that are used in DCE blocks so as to avoid the
> errors about them not existing. These empty definitions would have to be
> maintained in a set of external files or generated at compile time.
>
> There are actually a considerable number of missing funcs/vars used in DCE
> blocks. As an example i have attached a list of empty funcs/vars that I
> have been able to programmatically detect (there are a lot! and i may have
> missed some).

I like using this approach, but I think such files should only be added 
to the build if --disable-optimizations is passed into configure.  I 
think that's the sort of approach that most people could get behind 
since it won't affect the regular build.  I think it is okay if these .c 
files aren't perfect from the start, and while it would be nice if 
people that add new functions (or change existing function definitions) 
to arch (or similar) were to make appropriate changes to these files, if 
they don't, that's okay too.  There are likely a limited number of 
people that would choose to employ --disable-optimizations, and it is 
not a big deal to add a function or two to these files as they crop up 
and submit a patch for the changes.

Aaron