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

Submitted by James Almer on Oct. 1, 2017, 10:55 p.m.

Details

Message ID 20171001225529.9288-1-jamrial@gmail.com
State New
Headers show

Commit Message

James Almer Oct. 1, 2017, 10:55 p.m.
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@gmail.com>
---
FATE slots will love this, especially those running on disk space
deprived VMs.

 Makefile              |  6 +-----
 doc/examples/Makefile |  7 ++-----
 fftools/Makefile      | 10 +++++-----
 3 files changed, 8 insertions(+), 15 deletions(-)

Comments

Carl Eugen Hoyos Oct. 1, 2017, 11:18 p.m.
2017-10-02 0:55 GMT+02:00 James Almer <jamrial@gmail.com>:
> 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.

This makes it much more difficult to request backtrace etc.
from users.

A similar patch was rejected a few years ago.

Carl Eugen
James Almer Oct. 1, 2017, 11:20 p.m.
On 10/1/2017 8:18 PM, Carl Eugen Hoyos wrote:
> 2017-10-02 0:55 GMT+02:00 James Almer <jamrial@gmail.com>:
>> 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.
> 
> This makes it much more difficult to request backtrace etc.
> from users.

How so? The installed binaries are always stripped (unless configured
with --disable-stripping), with or without this patch.

> 
> A similar patch was rejected a few years ago.
> 
> Carl Eugen
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
Carl Eugen Hoyos Oct. 1, 2017, 11:22 p.m.
2017-10-02 1:20 GMT+02:00 James Almer <jamrial@gmail.com>:
> On 10/1/2017 8:18 PM, Carl Eugen Hoyos wrote:
>> 2017-10-02 0:55 GMT+02:00 James Almer <jamrial@gmail.com>:
>>> 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.
>>
>> This makes it much more difficult to request backtrace etc.
>> from users.
>
> How so? The installed binaries are always stripped (unless configured
> with --disable-stripping), with or without this patch.

We currently simply ask for "ffmpeg_g" output, even a user
who has no idea about debugging either has this executable
or not.

Carl Eugen
James Almer Oct. 1, 2017, 11:27 p.m.
On 10/1/2017 8:22 PM, Carl Eugen Hoyos wrote:
> 2017-10-02 1:20 GMT+02:00 James Almer <jamrial@gmail.com>:
>> On 10/1/2017 8:18 PM, Carl Eugen Hoyos wrote:
>>> 2017-10-02 0:55 GMT+02:00 James Almer <jamrial@gmail.com>:
>>>> 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.
>>>
>>> This makes it much more difficult to request backtrace etc.
>>> from users.
>>
>> How so? The installed binaries are always stripped (unless configured
>> with --disable-stripping), with or without this patch.
> 
> We currently simply ask for "ffmpeg_g" output, even a user
> who has no idea about debugging either has this executable
> or not.
> 
> Carl Eugen

Then we start asking for ffmpeg output. We always request testing and
backtraces using git head, and after this patch that will always be an
unstripped binary, so I don't get how this is an issue.
Carl Eugen Hoyos Oct. 1, 2017, 11:31 p.m.
2017-10-02 1:27 GMT+02:00 James Almer <jamrial@gmail.com>:
> On 10/1/2017 8:22 PM, Carl Eugen Hoyos wrote:
>> 2017-10-02 1:20 GMT+02:00 James Almer <jamrial@gmail.com>:
>>> On 10/1/2017 8:18 PM, Carl Eugen Hoyos wrote:
>>>> 2017-10-02 0:55 GMT+02:00 James Almer <jamrial@gmail.com>:
>>>>> 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.
>>>>
>>>> This makes it much more difficult to request backtrace etc.
>>>> from users.
>>>
>>> How so? The installed binaries are always stripped (unless configured
>>> with --disable-stripping), with or without this patch.
>>
>> We currently simply ask for "ffmpeg_g" output, even a user
>> who has no idea about debugging either has this executable
>> or not.
>
> Then we start asking for ffmpeg output. We always request testing and
> backtraces using git head, and after this patch that will always be an
> unstripped binary, so I don't get how this is an issue.

External packagers provide current binaries for all major operating
systems, so I don't understand how asking current git head is
related to asking debug information.

Carl Eugen
James Almer Oct. 1, 2017, 11:45 p.m.
On 10/1/2017 8:31 PM, Carl Eugen Hoyos wrote:
> 2017-10-02 1:27 GMT+02:00 James Almer <jamrial@gmail.com>:
>> On 10/1/2017 8:22 PM, Carl Eugen Hoyos wrote:
>>> 2017-10-02 1:20 GMT+02:00 James Almer <jamrial@gmail.com>:
>>>> On 10/1/2017 8:18 PM, Carl Eugen Hoyos wrote:
>>>>> 2017-10-02 0:55 GMT+02:00 James Almer <jamrial@gmail.com>:
>>>>>> 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.
>>>>>
>>>>> This makes it much more difficult to request backtrace etc.
>>>>> from users.
>>>>
>>>> How so? The installed binaries are always stripped (unless configured
>>>> with --disable-stripping), with or without this patch.
>>>
>>> We currently simply ask for "ffmpeg_g" output, even a user
>>> who has no idea about debugging either has this executable
>>> or not.
>>
>> Then we start asking for ffmpeg output. We always request testing and
>> backtraces using git head, and after this patch that will always be an
>> unstripped binary, so I don't get how this is an issue.
> 
> External packagers provide current binaries for all major operating
> systems, so I don't understand how asking current git head is
> related to asking debug information.

I'm honestly very confused. You do understand that the point of this
patch is to avoid a duplicate binary on the build folder and nothing
else, right? Installation is not affected. make install will behave
exactly the same after this patch as it had before, and that's what
external packagers package.
Michael Niedermayer Oct. 2, 2017, 7:34 p.m.
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@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



[...]
James Almer Oct. 2, 2017, 8:03 p.m.
On 10/2/2017 4:34 PM, Michael Niedermayer 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@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

What kind of confusion will removing "ffmpeg_g" from the build folder
bring? It's never installed, and what does get installed by "make
install" will not change with this patch in form or name.
This patch does for the binaries the same thing we're doing for the
libraries: Strip during install, instead of making a stripped duplicate
in the build folder.
wm4 Oct. 3, 2017, 8:18 a.m.
On Mon, 2 Oct 2017 21:34:18 +0200
Michael Niedermayer <michael@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@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.
James Almer Oct. 3, 2017, 1:23 p.m.
On 10/3/2017 5:18 AM, wm4 wrote:
> On Mon, 2 Oct 2017 21:34:18 +0200
> Michael Niedermayer <michael@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@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.

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.
wm4 Oct. 3, 2017, 1:27 p.m.
On Tue, 3 Oct 2017 10:23:08 -0300
James Almer <jamrial@gmail.com> wrote:

> On 10/3/2017 5:18 AM, wm4 wrote:
> > On Mon, 2 Oct 2017 21:34:18 +0200
> > Michael Niedermayer <michael@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@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.

> 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.
James Almer Oct. 3, 2017, 1:46 p.m.
On 10/3/2017 10:27 AM, wm4 wrote:
> On Tue, 3 Oct 2017 10:23:08 -0300
> James Almer <jamrial@gmail.com> wrote:
> 
>> On 10/3/2017 5:18 AM, wm4 wrote:
>>> On Mon, 2 Oct 2017 21:34:18 +0200
>>> Michael Niedermayer <michael@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@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.
Michael Niedermayer Oct. 3, 2017, 4:01 p.m.
On Mon, Oct 02, 2017 at 05:03:51PM -0300, James Almer wrote:
> On 10/2/2017 4:34 PM, Michael Niedermayer 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@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
> 
> What kind of confusion will removing "ffmpeg_g" from the build folder
> bring? It's never installed, and what does get installed by "make
> install" will not change with this patch in form or name.
> This patch does for the binaries the same thing we're doing for the
> libraries: Strip during install, instead of making a stripped duplicate
> in the build folder.

The ffmpeg in the build folder will be a different binary than the
one installed, they will look the same from the output, same
configure flags and so on.
But because they are different binaries they can and will behave
differently. Bugs in the past occuring with ffmpeg did sometimes not
reproduce with ffmpeg_g. But if one talked about "ffmpeg" or "ffmpeg_g"
together with its command line output which contains revission and
build flags it was clear what version was used.
With this change its indistingishable if a "ffmpeg" is stripped or non
stripped the printed build flags will no longer provide this
information together with the excuatble name


[...]
wm4 Oct. 3, 2017, 4:11 p.m.
On Tue, 3 Oct 2017 18:01:14 +0200
Michael Niedermayer <michael@niedermayer.cc> wrote:

> differently. Bugs in the past occuring with ffmpeg did sometimes not
> reproduce with ffmpeg_g. But if one talked about "ffmpeg" or "ffmpeg_g"
> together with its command line output which contains revission and
> build flags it was clear what version was used.

There are lots of factors that can make ffmpeg behave different on
every _invocation_. Like dynamic memory allocation or ASLR, or even the
ffmpeg binary path.

Should we remove all these features?
James Almer Oct. 3, 2017, 4:27 p.m.
On 10/3/2017 1:01 PM, Michael Niedermayer wrote:
> On Mon, Oct 02, 2017 at 05:03:51PM -0300, James Almer wrote:
>> On 10/2/2017 4:34 PM, Michael Niedermayer 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@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
>>
>> What kind of confusion will removing "ffmpeg_g" from the build folder
>> bring? It's never installed, and what does get installed by "make
>> install" will not change with this patch in form or name.
>> This patch does for the binaries the same thing we're doing for the
>> libraries: Strip during install, instead of making a stripped duplicate
>> in the build folder.
> 
> The ffmpeg in the build folder will be a different binary than the
> one installed, they will look the same from the output, same
> configure flags and so on.
> But because they are different binaries they can and will behave
> differently. Bugs in the past occuring with ffmpeg did sometimes not
> reproduce with ffmpeg_g. But if one talked about "ffmpeg" or "ffmpeg_g"
> together with its command line output which contains revission and
> build flags it was clear what version was used.

> With this change its indistingishable if a "ffmpeg" is stripped or non
> stripped the printed build flags will no longer provide this
> information together with the excuatble name

If the build flags have "--disable-stripping", then "ffmpeg" will not be
stripped, regardless of this being the build folder or an installation
target. So, in short, you're arguing that in builds with stripping
enabled, ffmpeg in the build folder being different than the one in the
install folder will make getting users to provide useful reports harder?

I don't really agree with this, seeing almost every other project out
there does pretty much what this patch is trying to achieve and don't
seem to have issues handling bug reports, but if both you and Carl
consider this behavior as important for the sake of bug reporting and
nobody else chimes in in favor, then I'll withdraw this patch.
Marton Balint Oct. 3, 2017, 5:06 p.m.
On Tue, 3 Oct 2017, James Almer wrote:

> On 10/3/2017 1:01 PM, Michael Niedermayer wrote:
>> On Mon, Oct 02, 2017 at 05:03:51PM -0300, James Almer wrote:
>>> On 10/2/2017 4:34 PM, Michael Niedermayer 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@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
>>>
>>> What kind of confusion will removing "ffmpeg_g" from the build folder
>>> bring? It's never installed, and what does get installed by "make
>>> install" will not change with this patch in form or name.
>>> This patch does for the binaries the same thing we're doing for the
>>> libraries: Strip during install, instead of making a stripped duplicate
>>> in the build folder.
>> 
>> The ffmpeg in the build folder will be a different binary than the
>> one installed, they will look the same from the output, same
>> configure flags and so on.
>> But because they are different binaries they can and will behave
>> differently. Bugs in the past occuring with ffmpeg did sometimes not
>> reproduce with ffmpeg_g. But if one talked about "ffmpeg" or "ffmpeg_g"
>> together with its command line output which contains revission and
>> build flags it was clear what version was used.
>
>> With this change its indistingishable if a "ffmpeg" is stripped or non
>> stripped the printed build flags will no longer provide this
>> information together with the excuatble name
>
> If the build flags have "--disable-stripping", then "ffmpeg" will not be
> stripped, regardless of this being the build folder or an installation
> target. So, in short, you're arguing that in builds with stripping
> enabled, ffmpeg in the build folder being different than the one in the
> install folder will make getting users to provide useful reports harder?
>
> I don't really agree with this, seeing almost every other project out
> there does pretty much what this patch is trying to achieve and don't
> seem to have issues handling bug reports, but if both you and Carl
> consider this behavior as important for the sake of bug reporting and
> nobody else chimes in in favor, then I'll withdraw this patch.

The only argument against this patch that I find mildly convincing is that 
we should do tests (fate tests) with stripped binaries in order to be able 
to detect bugs when stripping.

But I always hated the fact that the build process is copying huge 
binaries.

Question: why don't we use strip -o ffmpeg ffmpeg_g instead of copying 
first?

Regards,
Marton
wm4 Oct. 3, 2017, 5:11 p.m.
On Tue, 3 Oct 2017 13:27:21 -0300
James Almer <jamrial@gmail.com> wrote:

> I don't really agree with this, seeing almost every other project out
> there does pretty much what this patch is trying to achieve and don't
> seem to have issues handling bug reports, but if both you and Carl
> consider this behavior as important for the sake of bug reporting and
> nobody else chimes in in favor, then I'll withdraw this patch.

Sad...
James Almer Oct. 3, 2017, 5:16 p.m.
On 10/3/2017 2:11 PM, wm4 wrote:
> On Tue, 3 Oct 2017 13:27:21 -0300
> James Almer <jamrial@gmail.com> wrote:
> 
>> I don't really agree with this, seeing almost every other project out
>> there does pretty much what this patch is trying to achieve and don't
>> seem to have issues handling bug reports, but if both you and Carl
>> consider this behavior as important for the sake of bug reporting and
>> nobody else chimes in in favor, then I'll withdraw this patch.
> 
> Sad...

I don't have strong feelings for this patch. It's mean to free space
(seeing some clients in fate.ffmpeg.org keep running out of it) and
reduce building time. But if it ruins some people's workflow then I'm
not going to fight to get it in.

Patch hide | download patch | download mbox

diff --git a/Makefile b/Makefile
index 3007da50f7..1c6bc2fbb9 100644
--- a/Makefile
+++ b/Makefile
@@ -96,11 +96,7 @@  include $(SRC_PATH)/doc/examples/Makefile
 
 libavcodec/utils.o libavformat/utils.o libavdevice/avdevice.o libavfilter/avfilter.o libavutil/utils.o libpostproc/postprocess.o libswresample/swresample.o libswscale/utils.o : libavutil/ffversion.h
 
-$(PROGS): %$(PROGSSUF)$(EXESUF): %$(PROGSSUF)_g$(EXESUF)
-	$(CP) $< $@
-	$(STRIP) $@
-
-%$(PROGSSUF)_g$(EXESUF): $(FF_DEP_LIBS)
+$(PROGS): %$(PROGSSUF)$(EXESUF): $(FF_DEP_LIBS)
 	$(LD) $(LDFLAGS) $(LDEXEFLAGS) $(LD_O) $(OBJS-$*) $(FF_EXTRALIBS)
 
 VERSION_SH  = $(SRC_PATH)/ffbuild/version.sh
diff --git a/doc/examples/Makefile b/doc/examples/Makefile
index ff958d33c6..c813da4505 100644
--- a/doc/examples/Makefile
+++ b/doc/examples/Makefile
@@ -21,16 +21,14 @@  DOC_EXAMPLES-$(CONFIG_TRANSCODE_AAC_EXAMPLE)     += transcode_aac
 DOC_EXAMPLES-$(CONFIG_TRANSCODING_EXAMPLE)       += transcoding
 
 DOC_EXAMPLES       := $(DOC_EXAMPLES-yes:%=doc/examples/%$(PROGSSUF)$(EXESUF))
-DOC_EXAMPLES_G     := $(DOC_EXAMPLES-yes:%=doc/examples/%$(PROGSSUF)_g$(EXESUF))
 ALL_DOC_EXAMPLES   := $(DOC_EXAMPLES) $(DOC_EXAMPLES-:%=doc/examples/%$(PROGSSUF)$(EXESUF))
-ALL_DOC_EXAMPLES_G := $(DOC_EXAMPLES_G) $(DOC_EXAMPLES-:%=doc/examples/%$(PROGSSUF)_g$(EXESUF))
 PROGS              += $(DOC_EXAMPLES)
 
 EXAMPLES_FILES := $(wildcard $(SRC_PATH)/doc/examples/*.c) $(SRC_PATH)/doc/examples/README
 EXAMPLE_MAKEFILE := $(SRC_PATH)/doc/examples/Makefile
 
 $(foreach P,$(DOC_EXAMPLES),$(eval OBJS-$(P:%$(PROGSSUF)$(EXESUF)=%) = $(P:%$(PROGSSUF)$(EXESUF)=%).o))
-$(DOC_EXAMPLES_G): %$(PROGSSUF)_g$(EXESUF): %.o
+$(DOC_EXAMPLES): %$(PROGSSUF)$(EXESUF): %.o
 
 examples: $(DOC_EXAMPLES)
 
@@ -40,8 +38,7 @@  OBJDIRS += doc/examples
 DOXY_INPUT += $(DOC_EXAMPLES:%$(PROGSSUF)$(EXESUF)=%.c)
 
 examplesclean:
-	$(RM) $(ALL_DOC_EXAMPLES) $(ALL_DOC_EXAMPLES_G)
-	$(RM) $(CLEANSUFFIXES:%=doc/examples/%)
+	$(RM) $(ALL_DOC_EXAMPLES) $(CLEANSUFFIXES:%=doc/examples/%)
 
 docclean:: examplesclean
 
diff --git a/fftools/Makefile b/fftools/Makefile
index 094f6d6265..37ff131165 100644
--- a/fftools/Makefile
+++ b/fftools/Makefile
@@ -8,7 +8,6 @@  PROGS       += $(AVPROGS)
 
 AVBASENAMES  = ffmpeg ffplay ffprobe ffserver
 ALLAVPROGS   = $(AVBASENAMES:%=%$(PROGSSUF)$(EXESUF))
-ALLAVPROGS_G = $(AVBASENAMES:%=%$(PROGSSUF)_g$(EXESUF))
 
 OBJS-ffmpeg                        += fftools/ffmpeg_opt.o fftools/ffmpeg_filter.o fftools/ffmpeg_hw.o
 OBJS-ffmpeg-$(CONFIG_CUVID)        += fftools/ffmpeg_cuvid.o
@@ -22,11 +21,11 @@  OBJS-ffserver                      += fftools/ffserver_config.o
 define DOFFTOOL
 OBJS-$(1)-$(CONFIG_OPENCL) += fftools/cmdutils_opencl.o
 OBJS-$(1) += fftools/cmdutils.o fftools/$(1).o $(OBJS-$(1)-yes)
-$(1)$(PROGSSUF)_g$(EXESUF): $$(OBJS-$(1))
+$(1)$(PROGSSUF)$(EXESUF): $$(OBJS-$(1))
 $$(OBJS-$(1)): | fftools
 $$(OBJS-$(1)): CFLAGS  += $(CFLAGS-$(1))
-$(1)$(PROGSSUF)_g$(EXESUF): LDFLAGS += $(LDFLAGS-$(1))
-$(1)$(PROGSSUF)_g$(EXESUF): FF_EXTRALIBS += $(EXTRALIBS-$(1))
+$(1)$(PROGSSUF)$(EXESUF): LDFLAGS += $(LDFLAGS-$(1))
+$(1)$(PROGSSUF)$(EXESUF): FF_EXTRALIBS += $(EXTRALIBS-$(1))
 -include $$(OBJS-$(1):.o=.d)
 endef
 
@@ -47,6 +46,7 @@  install-progs-$(CONFIG_SHARED): install-libs
 install-progs: install-progs-yes $(AVPROGS)
 	$(Q)mkdir -p "$(BINDIR)"
 	$(INSTALL) -c -m 755 $(AVPROGS) "$(BINDIR)"
+	$(STRIP) $(addprefix "$(BINDIR)/", $(AVPROGS))
 
 uninstall: uninstall-progs
 
@@ -54,4 +54,4 @@  uninstall-progs:
 	$(RM) $(addprefix "$(BINDIR)/", $(ALLAVPROGS))
 
 clean::
-	$(RM) $(ALLAVPROGS) $(ALLAVPROGS_G) $(CLEANSUFFIXES:%=fftools/%)
+	$(RM) $(ALLAVPROGS) $(CLEANSUFFIXES:%=fftools/%)