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

[Ronald S. Bultje]

Hi Rune,

On Mon, Oct 3, 2016 at 10:26 AM, <u-9iep at aetey.se> wrote:

> 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??


I'm sure you understand that screaming around like a madman is unlikely to
improve anything.

- I don't want to litter the code with emms calls all around calls to libc
functions, certainly not every en/decoder, this would have to be in generic
code only;
- calling emms_c before calling user callbacks or malloc/free calls is
potentially doable, but doesn't make us abide to the standard in a literal
sense. We also need to go over the code and see how many changes this
requires;
- or we can just do what we do now and work with musl people to change
their code. If it turns out the first two are undoable and musl devs are
unwilling to do this, then we'll have to reconsider Carl's patch and call
musl on x86-32 unsupported, with a link to the relevant discussion to back
up our reasoning (to prevent bystanders from calling us trolls).

Again, this requires some time and thought.

Ronald