[FFmpeg-devel] [PATCH] build: don't strip binaries during compilation

[James Almer]

On 10/3/2017 10:27 AM, wm4 wrote:
> On Tue, 3 Oct 2017 10:23:08 -0300
> James Almer <jamrial at gmail.com> wrote:
> 
>> On 10/3/2017 5:18 AM, wm4 wrote:
>>> On Mon, 2 Oct 2017 21:34:18 +0200
>>> Michael Niedermayer <michael at niedermayer.cc> wrote:
>>>   
>>>> On Sun, Oct 01, 2017 at 07:55:29PM -0300, James Almer wrote:  
>>>>> Do it during install instead, like with the libraries.
>>>>>
>>>>> There's no benefit making a stripped copy of the CLI tools in the
>>>>> build folder. Doing it during install saves build time and storage
>>>>> space.
>>>>>
>>>>> Signed-off-by: James Almer <jamrial at gmail.com>    
>>>>
>>>> Iam not sure this is a good idea
>>>>
>>>> the build binaries and installed binaries would differ, thats bound
>>>> to lead to some confusion and problems  
>>>
>>> Uh, doing stripping on installing is pretty common.
>>>
>>> You know what I find confusing? That it's literally impossible to use a
>>> debugger on FFmpeg. There are a bunch of obscure flags which actually
>>> stop the damn build script from stripping the libs and which bring down
>>> the optimization level, but even then the forced DCE requirement fucks
>>> with debugging.  
>>
>> This has nothing to do with the patch and it's a discussion for another
>> thread.
> 
> The second part, sure. The first part not. autotools for example
> generates an install-strip target. AFAIK debug infos are always
> generated? In any case, that means it doesn't strip them in-tree.

Debug symbols are always generated and stripping always happens unless
--disable-debug and --disable-stripping are used respectively during
configure.

And yes, that's the point of this patch. Strip binaries on install and
keep the build folder free of duplicates, same as we do with shared
libraries. What gets installed is not affected.

> 
>> I'd like to focus specifically on the patch and its effects, as I'm
>> still trying to understand why two people say it would confuse users or
>> lead to problems.
> 
> At this point I think Michael is going to argue any change in behavior
> will be "confusing". With that attitude you can't fix anything.

I'd rather have him explain and not others guess or interpret, thanks.