[FFmpeg-devel] [PATCH] Workaround to build ffmpeg on MacOs 10.15

Michael Niedermayer michael at niedermayer.cc
Sat Jan 4 23:42:47 EET 2020


On Sat, Jan 04, 2020 at 10:35:59PM +0100, Michael Niedermayer wrote:
> On Sat, Jan 04, 2020 at 09:25:40PM +0200, Martin Storsjö wrote:
> > On Sat, 4 Jan 2020, Michael Niedermayer wrote:
> > 
> > >On Sat, Jan 04, 2020 at 12:06:55AM +0100, Henrik Gramner wrote:
> > >>On Fri, Jan 3, 2020 at 7:37 PM Moritz Barsnick <barsnick at gmx.net> wrote:
> > >>>On Fri, Jan 03, 2020 at 11:05:25 +0100, Timo Rothenpieler wrote:
> > >>>>I think this was discussed on this list in the past.
> > >>>>Not sure what the conclusion was, but I think an unconditional flag like
> > >>>>this being added wasn't all that well received.
> > >>>
> > >>>Yes, discussed in this thread in November:
> > >>>http://ffmpeg.org/pipermail/ffmpeg-devel/2019-November/253193.html
> > >>
> > >>Lmao "security feature". Just disable that flag and call it a day, it
> > >>adds nothing of value (unless you consider crashing to be a "security
> > >>feature"?).
> > >
> > >I dont know how effective this is or what exactly this option does, i
> > >couldnt find documentation for it quickly what it does in clang on macosx.
> > >google keeps pointing to gcc
> > >but
> > >
> > >a crash is better than arbitrary code execution, which IIUC is the idea
> > >here, if the stack of a thread grows too much, crash instead of overwriting
> > >something that comes after it.
> > >Not crashing when the stack overlapps another threads stack or heap is
> > >unlikely to be better.
> > 
> > The point here is, disabling this "feature" is not a security regression -
> > it's a new feature in apple's clang, which only is enabled when you target a
> > new enough version of macOS. And that new security feature is broken to the
> > point that the process crashes before you even get to code which may be
> > misbehaving.
> > 
> > So disabling it isn't a regression, it just takes things back to how things
> > were before, before this was introduced.
> 
> Is it difficult to detect if the compiler has this bug ?
> Iam asking because disabling this feature only when needed avoids the
> questions related to "what happens when it is fixed".
> 

> We could wait for it being fixed and then add a check on the
> version number and then backport that to any release which may need it.
> If it is difficult to add a check now

Clarifying this slightly as re-reading sounds ambigous
What i meant is to disable it for apple/clang now and then if its fixed
replace that by a version check. (if adding a check now is difficult)


[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The misfortune of the wise is better than the prosperity of the fool.
-- Epicurus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20200104/1dd91a66/attachment.sig>


More information about the ffmpeg-devel mailing list