diff mbox series

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

Message ID 20200103035543.55727-1-tfoucu@gmail.com
State New
Headers show
Series [FFmpeg-devel] Workaround to build ffmpeg on MacOs 10.15
Related show

Checks

Context Check Description
andriy/ffmpeg-patchwork pending
andriy/ffmpeg-patchwork success Applied patch
andriy/ffmpeg-patchwork success Configure finished
andriy/ffmpeg-patchwork success Make finished
andriy/ffmpeg-patchwork success Make fate finished

Commit Message

Thierry Foucu Jan. 3, 2020, 3:55 a.m. UTC
From: Thierry Foucu <tfoucu@gmail.com>

---
 configure | 3 +++
 1 file changed, 3 insertions(+)

Comments

Timo Rothenpieler Jan. 3, 2020, 10:05 a.m. UTC | #1
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.
Moritz Barsnick Jan. 3, 2020, 6:37 p.m. UTC | #2
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

Moritz
Thierry Foucu Jan. 3, 2020, 9:45 p.m. UTC | #3
On Fri, Jan 3, 2020 at 10:37 AM Moritz Barsnick <barsnick@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
>
>
Thanks Moritz.
So, right now, we cannot build ffmpeg with optimization on Mac Os 10.15.
note that VLC added such option in
https://git.videolan.org/?p=vlc.git;a=commit;h=856ddd8d1af955712c7effb1876ca9544b688cab

to build libav libraries...


> Moritz
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
Nicolas George Jan. 3, 2020, 9:56 p.m. UTC | #4
Thierry Foucu (12020-01-03):
> So, right now, we cannot build ffmpeg with optimization on Mac Os 10.15.

Can't you pass the option as extra-cflags to configure? It should work,
until a proper fix is proposed.

Regards,
Thierry Foucu Jan. 3, 2020, 10:04 p.m. UTC | #5
On Fri, Jan 3, 2020 at 1:56 PM Nicolas George <george@nsup.org> wrote:

> Thierry Foucu (12020-01-03):
> > So, right now, we cannot build ffmpeg with optimization on Mac Os 10.15.
>
> Can't you pass the option as extra-cflags to configure? It should work,
> until a proper fix is proposed.
>

Yes i can, but why should we have all the Mac user to do it until a fix is
proposed?
Is there any documentation on how to build ffmpeg on Mac where we can make
sure users know about passing this option as extra-cflags to configure?

if not, i think it will be best to have this option in configure so ffmpeg
users do not have to use some search engine to find out how to build ffmpeg
for Mac Os 10.15.


>
> Regards,
>
> --
>   Nicolas George
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
Henrik Gramner Jan. 3, 2020, 11:06 p.m. UTC | #6
On Fri, Jan 3, 2020 at 7:37 PM Moritz Barsnick <barsnick@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"?).
Michael Niedermayer Jan. 4, 2020, 1:37 p.m. UTC | #7
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@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.

That said, thats when things work, IIUC theres some kind of bug in the
apple compiler.
If that is true the workaround of disablng the flag should only be
enabled when a affected compiler is used

Thanks

[...]
Timo Rothenpieler Jan. 4, 2020, 2:27 p.m. UTC | #8
On 04.01.2020 14:37, Michael Niedermayer wrote:
> 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.
> 
> That said, thats when things work, IIUC theres some kind of bug in the
> apple compiler.
> If that is true the workaround of disablng the flag should only be
> enabled when a affected compiler is used

This seems to be a known bug for quite a while now, why did it not get 
fixed in the compiler yet?
Hendrik Leppkes Jan. 4, 2020, 2:35 p.m. UTC | #9
On Sat, Jan 4, 2020 at 3:27 PM Timo Rothenpieler <timo@rothenpieler.org> wrote:
>
> On 04.01.2020 14:37, Michael Niedermayer wrote:
> > 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.
> >
> > That said, thats when things work, IIUC theres some kind of bug in the
> > apple compiler.
> > If that is true the workaround of disablng the flag should only be
> > enabled when a affected compiler is used
>
> This seems to be a known bug for quite a while now, why did it not get
> fixed in the compiler yet?

Because it doesn't affect Apple themselves, and reaction time to
external bug reports is in months at best.

- Hendrik
Limin Wang Jan. 4, 2020, 4:02 p.m. UTC | #10
On Sat, Jan 04, 2020 at 03:35:42PM +0100, Hendrik Leppkes wrote:
> On Sat, Jan 4, 2020 at 3:27 PM Timo Rothenpieler <timo@rothenpieler.org> wrote:
> >
> > On 04.01.2020 14:37, Michael Niedermayer wrote:
> > > 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.
> > >
> > > That said, thats when things work, IIUC theres some kind of bug in the
> > > apple compiler.
> > > If that is true the workaround of disablng the flag should only be
> > > enabled when a affected compiler is used
> >
> > This seems to be a known bug for quite a while now, why did it not get
> > fixed in the compiler yet?
> 
> Because it doesn't affect Apple themselves, and reaction time to
> external bug reports is in months at best.

https://trac.macports.org/ticket/58776

> 
> - Hendrik
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
Martin Storsjö Jan. 4, 2020, 7:25 p.m. UTC | #11
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@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.

// Martin
Michael Niedermayer Jan. 4, 2020, 9:35 p.m. UTC | #12
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@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

Also what is your oppinion about limiting disabling the flag for only
apple/clang ?

Thanks

[...]
Michael Niedermayer Jan. 4, 2020, 9:42 p.m. UTC | #13
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@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)


[...]
diff mbox series

Patch

diff --git a/configure b/configure
index 965b4c71b8..0bc2cb52ac 100755
--- a/configure
+++ b/configure
@@ -5317,6 +5317,9 @@  case $target_os in
         enabled x86_32 && append SHFLAGS -Wl,-read_only_relocs,suppress
         strip="${strip} -x"
         add_ldflags -Wl,-dynamic,-search_paths_first
+        # -fno-stack-check is a workaround for a possible
+        # bug in Xcode 11 or macOS 10.15+
+        add_cflags -fno-stack-check
         check_cflags -Werror=partial-availability
         SLIBSUF=".dylib"
         SLIBNAME_WITH_VERSION='$(SLIBPREF)$(FULLNAME).$(LIBVERSION)$(SLIBSUF)'