[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