| Message ID | 20200103035543.55727-1-tfoucu@gmail.com |
|---|---|
| State | Withdrawn |
| Headers | show |
| Series | [FFmpeg-devel] Workaround to build ffmpeg on MacOs 10.15 | expand |
| Context | Check | Description |
|---|---|---|
| andriy/ffmpeg-patchwork | success | Make fate finished |
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.
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
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".
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,
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".
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"?).
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 [...]
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?
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
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".
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
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 [...]
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 --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)'
From: Thierry Foucu <tfoucu@gmail.com> --- configure | 3 +++ 1 file changed, 3 insertions(+)