[FFmpeg-devel] [PATCH] Makefile: generate stripped CLI tools directly instead of copying unstripped ones first

Marton Balint cus at passwd.hu
Sat Oct 7 12:18:31 EEST 2017



On Fri, 6 Oct 2017, James Almer wrote:

> On 10/6/2017 8:20 PM, James Almer wrote:
>> On 10/6/2017 5:20 PM, Marton Balint wrote:
>>> Signed-off-by: Marton Balint <cus at passwd.hu>
>>> ---
>>>  Makefile | 3 +--
>>>  1 file changed, 1 insertion(+), 2 deletions(-)
>>>
>>> diff --git a/Makefile b/Makefile
>>> index 4a1253a052..adb8330fa0 100644
>>> --- a/Makefile
>>> +++ b/Makefile
>>> @@ -97,8 +97,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) $@
>>> +	$(STRIP) -o $@ $<
>> 
>> LGTM. This is the best thing after stripping on install, which seems to
>> be disliked.
>
> Actually, configure seems to consider cases where STRIP is something
> else than binutils' strip.
>
> I guess it's known and tested to work with the to-be-stripped binary as
> the only argument, but would -o work with every potential strip program,
> or for that matter binutils on every supported platform? I already got
> bitten by MacOS's install not accepting -T.

With the v2 patch I sent, more cases are handled when strip is not a 
traditional strip command.

I did a quick check of online man pages, and it seems to me only some very 
uncommon or very old platforms does not support -o.

So I can either keep the patch as is, (with direct stripping turned on 
by default) and fix OS/platforms as fate detects them, or we can make it 
opt-in for the known platforms, if we are very afraid of breaking stuff.

Regards,
Marton


More information about the ffmpeg-devel mailing list