From: Hans-Christian Egtvedt <hans-christian.egtvedt@atmel.com>
To: buildroot@busybox.net
Subject: [Buildroot] Status of "mplayer" in buildroot
Date: Tue, 20 Jan 2009 07:27:38 +0100 [thread overview]
Message-ID: <20090120072738.77f10839@hcegtvedt> (raw)
In-Reply-To: <1232395188.4539.20.camel@elrond.atmel.com>
On Mon, 19 Jan 2009 20:59:47 +0100
Ulf Samuelsson <ulf.samuelsson@atmel.com> wrote:
> Anyone beeing able to build "mplayer" at all?
>
> I have been trying to get that to build for some time now.
>
> There are several problems:
>
> 1: Current mplayer relies on an older version of alsa-lib
> The current version of alsa-lib make some routines "local"
> by statements like:
>
> #define snd_XXXX snd1_XXXX
>
> mplayer uses some of these routines and the build will not
> complete.
>
I added a patch to the repository to fix compilation against the new
alsa library. MPlayer compiles and runs again :) Tested only on AVR32.
> 2) mplayer do not have any recent "versions".
> Instead you are encouraged to checkout the latest svn.
>
It is just plain bad to depend on a random checkout. Perhaps we can use
debians/ubuntus "release"?
MPlayer v1.0rc2 + mplayer_1.0~rc2-0ubuntu17.diff.gz ?
When I look more into it, the Ubuntu diff is just adding pulse audio
support and various version and other doc changes.
> The build of this will fail using the current Buildroot mplayer.mk,
> since you have to prepare the mplayer source tree by:
>
> ./configure
> make codec.conf.h # This is created using native gcc.
>
> And once this is complete, then the buildroot mplayer.mk
> can be applied on top.
>
> The AVR32 patches do not apply clean on the current svn, but
> since I believe mplayer do not build anyway, for any architecture
> that means that there should be no problem upgrading mplayer
> to the latest version.
>
> I *have* created a new version of the AVR patches that applies
> clean on top of the current svn. Not fully tested yet.
> HCE you want to test?
>
Sure, feel free to send me the diff, then I can work on getting it
ready for submission upstream.
> I am not particlary fond of downloading the latest svn,
> since that is a recipy for breakage.
> I think we should have a recommended version of mplayer
> (which we have tested on many architectures)
> as well as the capability to checkout the latest.
>
I say we at least move to v1.0rc2, but lets worry about that after the
release. The quick fix I did should get it working as it is now.
--
Best regards,
Hans-Christian Egtvedt
next prev parent reply other threads:[~2009-01-20 6:27 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-01-19 19:59 [Buildroot] Status of "mplayer" in buildroot Ulf Samuelsson
2009-01-20 6:27 ` Hans-Christian Egtvedt [this message]
2009-01-20 7:57 ` Markus Heidelberg
2009-01-20 8:07 ` Hans-Christian Egtvedt
2009-01-20 9:36 ` Peter Korsgaard
2009-01-20 9:34 ` Peter Korsgaard
2009-01-20 9:33 ` Peter Korsgaard
2009-01-20 11:00 ` Ulf Samuelsson
2009-01-20 11:29 ` Peter Korsgaard
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20090120072738.77f10839@hcegtvedt \
--to=hans-christian.egtvedt@atmel.com \
--cc=buildroot@busybox.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.