[FFmpeg-devel] [PATCH]doc/platform: Mention musl where x86_32 is not supported

u-9iep at aetey.se u-9iep at aetey.se
Mon Oct 3 17:26:50 EEST 2016

On Mon, Oct 03, 2016 at 08:01:05AM -0400, Ronald S. Bultje wrote:
> > Ping on the patch:

> The patch is unlikely to assist in fixing the issue and is likely to cause
> further inflammation. Therefore I would prefer you did not apply the patch
> and also please don't send a new version that is differently worded.
> I would prefer to work with upstream (musl) and fix the issue where ffmpeg
> running with musl crashes. Whether that means changing ffmpeg or musl
> remains to be seen. Let's chat with the developers and figure something out.

The standard C library API is what it is called, a standard.

What you are talking about is to ask Rich to modify musl to hide ffmpeg's
non-compliance bug (which glibc/uclibc do by sheer luck but this may change
any time).

With all the competence present here, is it really infeasible to improve
the code structure so that it does not involve the C library in the
bit-crunching performance critical paths??


More information about the ffmpeg-devel mailing list