[MPlayer-dev-eng] [PATCH 2/2] Fix compilation with recent FFmpeg on ARM

Alexander Strasser eclipse7 at gmx.net
Wed Apr 1 00:37:44 CEST 2015


Hi Laurent!

On 2015-03-31 10:38 -0400, Laurent wrote:
> On Sat, Mar 14, 2015 at 9:21 PM, Alexander Strasser <eclipse7 at gmx.net> wrote:
> > On 2015-03-13 18:18 -0400, Laurent wrote:
> > > Not sure about this one: HAVE_SECTION_DATA_REL_RO.
> > > It is defined for Android and Linux, see:
> > > http://lists.libav.org/pipermail/libav-commits/2014-December/015860.html
> > > So I lazily hardcoded it:
> >
> >   Thank you for both of your patches. Fixes build on ARM here.
> >
> >   Your patch got line-wrapped though. You should be able to
> > notice it by e.g. by looking at the ML archive. If you cannot
> > get it through unmangled, consider attaching the patch next time.
> > For this time I repaired it manually myself.
> 
> Sorry about the mangling. The HTML version of the mail is correct so I
> failed to see this issue initially.
> Any chance to get this committed?

  I was about to commit it but I decided to delay a bit more. So
sorry about that.
  
  I am a bit unsure testing it as inline asm block in configure is
correct. The code in question might be compiled by a different
assembler. Now I do not know if we really have that many possibilities
in reality as for now, but then OTOH we want to avoid making such
assumptions based on the current situation.

> >   As for the question for when to define HAVE_SECTION_DATA_REL_RO:
> > I do not have much knowledge about the ARM platform. I only used
> > it with Linux so far. As far as Linux vs Android is concerned, I
> > do not think we differentiate Linux and Android in MPlayer at all.
> >
> >   Maybe some other developer can comment. Reimar?
> 
> ping

  I applied a patch that does define it to zero. That alone is
enough to fix compilation for me. Defining it to one should be
better though and working with the usual toolchain on Linux
systems.

> > > By the way... is there still benefits to compile MPlayer with the internal FFmpeg instead of using an external one (as the later is less subject to configure breakage)?
> 
> ping, as well.

  I didn't put too much thought and work in this part of the
answer at this time of the day, please don't take it too seriously ;)

  I guess if you are on a modern platform many benefits of
internal/static FFmpeg are gone. I do not know for ARM though.
I do not know very much about the ARM architecture. I certainly
did build MPlayer with external FFmpeg not too long ago and the
resulting binaries were quite usable I think.

  So IMHO feel free to build with external FFmpeg, and be
sure to report/fix bugs should you come across them. If a
feature that you use is missing, I think you would notice.


  Now regarding configure breakage, it sure is a problem we
need to tackle. I will give it shot, but not before we have
made a new release.

Hope I could help a bit and sorry for being slow,
  Alexander
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <https://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20150401/06b186fa/attachment.asc>


More information about the MPlayer-dev-eng mailing list