[PATCH] angstrom-2008.1: bump uclibc to 0.9.30.3 which unbreaks x264

[PATCH] angstrom-2008.1: bump uclibc to 0.9.30.3 which unbreaks x264

[Petr Štetiar]

Fixes the compile problem:

x264-r2245-r7/x264-snapshot-20100531-2245/encoder/set.c:236: undefined reference to `log2f'
libx264.a(encoder.o): In function `x264_validate_parameters':

Signed-off-by: Petr Štetiar <ynezz@true.cz>
---
 conf/distro/angstrom-2008.1.conf |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/conf/distro/angstrom-2008.1.conf b/conf/distro/angstrom-2008.1.conf
index 1fd5ab6..895deed 100644
--- a/conf/distro/angstrom-2008.1.conf
+++ b/conf/distro/angstrom-2008.1.conf
@@ -78,8 +78,8 @@ PREFERRED_VERSION_linux-libc-headers-native = "${LINUX_LIBC_HEADERS_VERSION}"
 #Prefer glibc 2.6 and uclibc 0.9.30, these have had the most testing.
 PREFERRED_VERSION_glibc 			?= "2.9"
 PREFERRED_VERSION_glibc-initial 	?= "2.9"
-PREFERRED_VERSION_uclibc        	?= "0.9.30.2"
-PREFERRED_VERSION_uclibc-initial	?= "0.9.30.2"
+PREFERRED_VERSION_uclibc        	?= "0.9.30.3"
+PREFERRED_VERSION_uclibc-initial	?= "0.9.30.3"
 PREFERRED_VERSION_eglibc			?= "2.9"
 PREFERRED_VERSION_eglibc-initial	?= "2.9"
 
-- 
1.7.0.4

Re: [PATCH] angstrom-2008.1: bump uclibc to 0.9.30.3 which unbreaks x264

[Andrea Adami]

> -PREFERRED_VERSION_uclibc               ?= "0.9.30.2"
> -PREFERRED_VERSION_uclibc-initial       ?= "0.9.30.2"
> +PREFERRED_VERSION_uclibc               ?= "0.9.30.3"
> +PREFERRED_VERSION_uclibc-initial       ?= "0.9.30.3"

Hi,

this would only fix x264/freempeg.

Unfortunately build will fail on e2fsprogs afterwards.
See http://lists.linuxtogo.org/pipermail/angstrom-distro-devel/2010-November/004257.html

So I suppose we should do a combined upgrade of uclibc and binutils.
I'll test with current gcc-4.3.3 and let you know.

Andrea

Re: [PATCH] angstrom-2008.1: bump uclibc to 0.9.30.3 which unbreaks x264

[Petr Štetiar]

Andrea Adami <andrea.adami@gmail.com> [2010-11-26 11:53:50]:

> > -PREFERRED_VERSION_uclibc               ?= "0.9.30.2"
> > -PREFERRED_VERSION_uclibc-initial       ?= "0.9.30.2"
> > +PREFERRED_VERSION_uclibc               ?= "0.9.30.3"
> > +PREFERRED_VERSION_uclibc-initial       ?= "0.9.30.3"
> 
> Hi,

Hi,

> Unfortunately build will fail on e2fsprogs afterwards.
> See http://lists.linuxtogo.org/pipermail/angstrom-distro-devel/2010-November/004257.html

ok, so then I'll fix e2fsprogs :-)

> So I suppose we should do a combined upgrade of uclibc and binutils.
> I'll test with current gcc-4.3.3 and let you know.

Ok, I don't mind how, just fix it please, it's all errors on release-2010.12
branch...

-- ynezz

Re: [PATCH] angstrom-2008.1: bump uclibc to 0.9.30.3 which unbreaks x264

[Koen Kooi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 26-11-10 11:53, Andrea Adami wrote:
>> -PREFERRED_VERSION_uclibc               ?= "0.9.30.2"
>> -PREFERRED_VERSION_uclibc-initial       ?= "0.9.30.2"
>> +PREFERRED_VERSION_uclibc               ?= "0.9.30.3"
>> +PREFERRED_VERSION_uclibc-initial       ?= "0.9.30.3"
> 
> Hi,
> 
> this would only fix x264/freempeg.
> 
> Unfortunately build will fail on e2fsprogs afterwards.
> See http://lists.linuxtogo.org/pipermail/angstrom-distro-devel/2010-November/004257.html
> 
> So I suppose we should do a combined upgrade of uclibc and binutils.
> I'll test with current gcc-4.3.3 and let you know.

An upgrade of binutils is out of the question for angstrom 2008.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFM75gYMkyGM64RGpERAo2GAJ9AQf8ixLASkpLnUwVhK0iRaYZgLACfQl/k
hE6j+z4EssvPc0A+tiDN1OY=
=UYoM
-----END PGP SIGNATURE-----

Re: [PATCH] angstrom-2008.1: bump uclibc to 0.9.30.3 which unbreaks x264

[Andrea Adami]

>> So I suppose we should do a combined upgrade of uclibc and binutils.
>> I'll test with current gcc-4.3.3 and let you know.

FWIW angstrom-2008.1 console, opie, x11, x11-gpe images build fine
with binutils "2.20.1" and uclibc "git" like minimal distro but  with
gcc-4.3.3.

> An upgrade of binutils is out of the question for angstrom 2008.

I understand, too late now.
Shame on us for the lack of uclibc testing :/

Regards

Andrea

[PATCH] x264-r2245: add a hack for uclibc - replace log2f(x) with logf(x)/logf(2)

[Bernhard.Guillon]

From: Bernhard Guillon <Bernhard.Guillon@opensimpad.org>


Signed-off-by: Bernhard Guillon <Bernhard.Guillon@opensimpad.org>
---
 recipes/vlc/x264-r2245/uclibc_log2f_fix.HACK.patch |   61 ++++++++++++++++++++
 recipes/vlc/x264_r2245.bb                          |    6 +-
 2 files changed, 64 insertions(+), 3 deletions(-)
 create mode 100644 recipes/vlc/x264-r2245/uclibc_log2f_fix.HACK.patch

diff --git a/recipes/vlc/x264-r2245/uclibc_log2f_fix.HACK.patch b/recipes/vlc/x264-r2245/uclibc_log2f_fix.HACK.patch
new file mode 100644
index 0000000..874a0ca
--- /dev/null
+++ b/recipes/vlc/x264-r2245/uclibc_log2f_fix.HACK.patch
@@ -0,0 +1,61 @@
+diff -Nur x264-snapshot-20100531-2245.vanilla/encoder/analyse.c x264-snapshot-20100531-2245/encoder/analyse.c
+--- x264-snapshot-20100531-2245.vanilla/encoder/analyse.c	2010-05-31 22:45:11.000000000 +0200
++++ x264-snapshot-20100531-2245/encoder/analyse.c	2010-08-20 02:52:11.505161943 +0200
+@@ -251,7 +251,7 @@
+     for( int i = 0; i <= 2*4*2048; i++ )
+     {
+         h->cost_mv[lambda][-i] =
+-        h->cost_mv[lambda][i]  = lambda * (log2f(i+1)*2 + 0.718f + !!i) + .5f;
++        h->cost_mv[lambda][i]  = lambda * ( (logf(i+1)/logf(2))*2 + 0.718f + !!i) + .5f;
+     }
+     x264_pthread_mutex_lock( &cost_ref_mutex );
+     for( int i = 0; i < 3; i++ )
+diff -Nur x264-snapshot-20100531-2245.vanilla/encoder/encoder.c x264-snapshot-20100531-2245/encoder/encoder.c
+--- x264-snapshot-20100531-2245.vanilla/encoder/encoder.c	2010-05-31 22:45:11.000000000 +0200
++++ x264-snapshot-20100531-2245/encoder/encoder.c	2010-08-20 02:53:58.516661776 +0200
+@@ -479,8 +479,8 @@
+     if( h->param.rc.i_rc_method == X264_RC_CQP )
+     {
+         float qp_p = h->param.rc.i_qp_constant;
+-        float qp_i = qp_p - 6*log2f( h->param.rc.f_ip_factor );
+-        float qp_b = qp_p + 6*log2f( h->param.rc.f_pb_factor );
++        float qp_i = qp_p - 6*(logf(h->param.rc.f_ip_factor)/logf(2));
++        float qp_b = qp_p + 6*(logf(h->param.rc.f_pb_factor)/logf(2));
+         h->param.rc.i_qp_min = x264_clip3( (int)(X264_MIN3( qp_p, qp_i, qp_b )), 0, 51 );
+         h->param.rc.i_qp_max = x264_clip3( (int)(X264_MAX3( qp_p, qp_i, qp_b ) + .999), 0, 51 );
+         h->param.rc.i_aq_mode = 0;
+diff -Nur x264-snapshot-20100531-2245.vanilla/encoder/ratecontrol.c x264-snapshot-20100531-2245/encoder/ratecontrol.c
+--- x264-snapshot-20100531-2245.vanilla/encoder/ratecontrol.c	2010-05-31 22:45:11.000000000 +0200
++++ x264-snapshot-20100531-2245/encoder/ratecontrol.c	2010-08-20 02:55:26.752661912 +0200
+@@ -549,8 +549,8 @@
+         rc->last_non_b_pict_type = SLICE_TYPE_I;
+     }
+ 
+-    rc->ip_offset = 6.0 * log2f( h->param.rc.f_ip_factor );
+-    rc->pb_offset = 6.0 * log2f( h->param.rc.f_pb_factor );
++    rc->ip_offset = 6.0 * (logf( h->param.rc.f_ip_factor )/logf(2));
++    rc->pb_offset = 6.0 * (logf( h->param.rc.f_pb_factor )/logf(2));
+     rc->qp_constant[SLICE_TYPE_P] = h->param.rc.i_qp_constant;
+     rc->qp_constant[SLICE_TYPE_I] = x264_clip3( h->param.rc.i_qp_constant - rc->ip_offset + 0.5, 0, 51 );
+     rc->qp_constant[SLICE_TYPE_B] = x264_clip3( h->param.rc.i_qp_constant + rc->pb_offset + 0.5, 0, 51 );
+@@ -1154,7 +1154,7 @@
+             if( zone->b_force_qp )
+                 q += zone->i_qp - rc->qp_constant[SLICE_TYPE_P];
+             else
+-                q -= 6*log2f( zone->f_bitrate_factor );
++                q -= 6*(logf( zone->f_bitrate_factor )/logf(2));
+         }
+     }
+ 
+diff -Nur x264-snapshot-20100531-2245.vanilla/encoder/set.c x264-snapshot-20100531-2245/encoder/set.c
+--- x264-snapshot-20100531-2245.vanilla/encoder/set.c	2010-05-31 22:45:11.000000000 +0200
++++ x264-snapshot-20100531-2245/encoder/set.c	2010-08-20 02:58:19.400661820 +0200
+@@ -234,7 +234,7 @@
+         sps->vui.i_max_bytes_per_pic_denom = 0;
+         sps->vui.i_max_bits_per_mb_denom = 0;
+         sps->vui.i_log2_max_mv_length_horizontal =
+-        sps->vui.i_log2_max_mv_length_vertical = (int)log2f( X264_MAX( 1, param->analyse.i_mv_range*4-1 ) ) + 1;
++        sps->vui.i_log2_max_mv_length_vertical = (int)(logf( X264_MAX( 1, param->analyse.i_mv_range*4-1 ))/logf(2))  + 1;
+     }
+ }
+ 
diff --git a/recipes/vlc/x264_r2245.bb b/recipes/vlc/x264_r2245.bb
index f533bfc..f685c63 100644
--- a/recipes/vlc/x264_r2245.bb
+++ b/recipes/vlc/x264_r2245.bb
@@ -1,10 +1,12 @@
 DESCRIPTION = "H.264 encoder"
 LICENSE = "GPL"
-PR = "r7"
+PR = "r8"
 
 X264PV = "snapshot-20100531-2245"
 
 SRC_URI = "http://download.videolan.org/pub/videolan/x264/snapshots/x264-${X264PV}.tar.bz2"
+SRC_URI_append_libc-uclibc = "file://uclibc_log2f_fix.HACK.patch" 
+
 SRC_URI[md5sum] = "d1ccb8122bd418291a9576a2bffdf662"
 SRC_URI[sha256sum] = "929e946947701a0b3a336a4b9cfe65daf4c52480f45d4363335ae2a3d5596fa9"
 
@@ -24,5 +26,3 @@ X264_DISABLE_ASM_x86 = ""
 DEPENDS_x86 = "yasm-native"
 
 EXTRA_OECONF = '--enable-shared ${X264_DISABLE_ASM} --extra-cflags="${X264_ECFLAGS}"'
-
-
-- 
1.7.1

Re: [PATCH] angstrom-2008.1: bump uclibc to 0.9.30.3 which unbreaks x264

[Bernhard Guillon]

On 26.11.2010 11:53, Andrea Adami wrote:
>
> this would only fix x264/freempeg.

Hi, I just sent a patch to the list which fixes x264 with a hack that 
simply replaces all occurrences of log2f(x) with logf(x)/logf(2).

best regards
Bernhard Guillon

Re: [PATCH] angstrom-2008.1: bump uclibc to 0.9.30.3 which unbreaks x264

[Petr Štetiar]

Koen Kooi <k.kooi@student.utwente.nl> [2010-11-26 12:20:56]:

> An upgrade of binutils is out of the question for angstrom 2008.

Ok, what do you suggest to fix that uclibc breakage which happens with
angstrom-2008 and angstrom-2010[1] (it's with mesa fix applied). Thanks.

1. http://tinderbox.openembedded.net/packages/1099789/

-- ynezz

Re: [PATCH] angstrom-2008.1: bump uclibc to 0.9.30.3 which unbreaks x264

[Andrea Adami]

Ok, then I suggest to stay with 0.9.30.2 and add the two hacks documented here:

1) replacing log2f(i) with logf(i)/logf(2)
http://www.mail-archive.com/uclibc@uclibc.org/msg04949.html
2) '--disable-tls' for e2fsprogs
http://patchwork.openembedded.org/patch/2069/

openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>

Opinions?

Andrea

Re: [PATCH] angstrom-2008.1: bump uclibc to 0.9.30.3 which unbreaks x264

[Andrea Adami]

On Sat, Nov 27, 2010 at 3:13 PM, Andrea Adami <andrea.adami@gmail.com> wrote:
> Ok, then I suggest to stay with 0.9.30.2 and add the two hacks documented here:
>
> 1) replacing log2f(i) with logf(i)/logf(2)
> http://www.mail-archive.com/uclibc@uclibc.org/msg04949.html

Patch courtesy of Bernhard Guillon already done (bad that OE Patchwork
is down...)
http://lists.linuxtogo.org/pipermail/openembedded-devel/2010-November/027326.html

> 2) '--disable-tls' for e2fsprogs
> http://patchwork.openembedded.org/patch/2069/
>

Here the patch is trivial...my concern is both should be Angstrom-only, isn't?


Andrea

Re: [PATCH] angstrom-2008.1: bump uclibc to 0.9.30.3 which unbreaks x264

[Bernhard Guillon]

On 27.11.2010 15:27, Andrea Adami wrote:
> On Sat, Nov 27, 2010 at 3:13 PM, Andrea Adami<andrea.adami@gmail.com>  wrote:
>    
>> Ok, then I suggest to stay with 0.9.30.2 and add the two hacks documented here:
>>
>> 1) replacing log2f(i) with logf(i)/logf(2)
>> http://www.mail-archive.com/uclibc@uclibc.org/msg04949.html
>>      
> Patch courtesy of Bernhard Guillon already done (bad that OE Patchwork
> is down...)
> http://lists.linuxtogo.org/pipermail/openembedded-devel/2010-November/027326.html
>
>    
>> 2) '--disable-tls' for e2fsprogs
>> http://patchwork.openembedded.org/patch/2069/
>>
>>      
> Here the patch is trivial...my concern is both should be Angstrom-only, isn't?
>
>    

This is true. We could add some python foo and check for angstrom? In my 
opinion the log2f patch is of no real harm. The tls support might be a 
problem.

Best regrads
Bernhard Guillon

Re: [PATCH] angstrom-2008.1: bump uclibc to 0.9.30.3 which unbreaks x264

[Petr Štetiar]

Bernhard Guillon <Bernhard.Guillon@opensimpad.org> [2010-12-01 12:41:31]:

> This is true. We could add some python foo and check for angstrom? In my  
> opinion the log2f patch is of no real harm. The tls support might be a  
> problem.

Why to not move to some newer version of uClibc directly, without that patch
at all?

-- ynezz

Re: [PATCH] angstrom-2008.1: bump uclibc to 0.9.30.3 which unbreaks x264

[Graeme Gregory]

On 01/12/2010 11:58, Petr Štetiar wrote:
> Bernhard Guillon <Bernhard.Guillon@opensimpad.org> [2010-12-01 12:41:31]:
>
>> This is true. We could add some python foo and check for angstrom? In my  
>> opinion the log2f patch is of no real harm. The tls support might be a  
>> problem.
> Why to not move to some newer version of uClibc directly, without that patch
> at all?
>
because Angstrom 2008.1 is an already released distro. We don't like
switching toolchains at last minute.

Graeme

Re: [PATCH] angstrom-2008.1: bump uclibc to 0.9.30.3 which unbreaks x264

[Andrea Adami]

On Wed, Dec 1, 2010 at 12:58 PM, Petr Štetiar <ynezz@true.cz> wrote:
> Bernhard Guillon <Bernhard.Guillon@opensimpad.org> [2010-12-01 12:41:31]:
>
>> This is true. We could add some python foo and check for angstrom? In my
>> opinion the log2f patch is of no real harm. The tls support might be a
>> problem.

it seems so, khem hinted about git needing tls

>
> Why to not move to some newer version of uClibc directly, without that patch
> at all?
>
> -- ynezz

uclibc-0.9.30.3 needs binutils 2.20.1

>Koen:
>An upgrade of binutils is out of the question for angstrom 2008.

so here we stay


Andrea

Re: [PATCH] angstrom-2008.1: bump uclibc to 0.9.30.3 which unbreaks x264

[Andrea Adami]

>>> This is true. We could add some python foo and check for angstrom? In my
>>> opinion the log2f patch is of no real harm. The tls support might be a
>>> problem.

About the tls:

http://bugs.gentoo.org/204102

... in e2fsprogs-1.40.4 the way uuids are generated has changed
(http://e2fsprogs.sourceforge.net/e2fsprogs-release.html#1.40.4).
e2fsprogs-1.40.3 works fine!

Perhaps Angstrom-2008.1 could pin 1.40.3

Andrea

Re: [PATCH] angstrom-2008.1: bump uclibc to 0.9.30.3 which unbreaks x264

[Frans Meulenbroeks]

2010/12/1 Andrea Adami <andrea.adami@gmail.com>:
>>>> This is true. We could add some python foo and check for angstrom? In my
>>>> opinion the log2f patch is of no real harm. The tls support might be a
>>>> problem.
>
> About the tls:
>
> http://bugs.gentoo.org/204102
>
> ... in e2fsprogs-1.40.4 the way uuids are generated has changed
> (http://e2fsprogs.sourceforge.net/e2fsprogs-release.html#1.40.4).
> e2fsprogs-1.40.3 works fine!
>
> Perhaps Angstrom-2008.1 could pin 1.40.3
>
> Andrea

You lost me here!

frans@frans-desktop:~/workspace/openembedded/recipes$ ls e2fs*
e2fsprogs_1.41.9.bb  e2fsprogs.inc

There is no 1.40.3 (git head master)

Frans

Re: [PATCH] x264-r2245: add a hack for uclibc - replace log2f(x) with logf(x)/logf(2)

[Graeme Gregory]

Thanks for this patch, have applied modified to apply for avr32 only as
that platform cannot move toolchains.

Graeme

On 26/11/2010 23:22, Bernhard.Guillon@opensimpad.org wrote:
> From: Bernhard Guillon <Bernhard.Guillon@opensimpad.org>
> 
> 
> Signed-off-by: Bernhard Guillon <Bernhard.Guillon@opensimpad.org>
> ---
>  recipes/vlc/x264-r2245/uclibc_log2f_fix.HACK.patch |   61 ++++++++++++++++++++
>  recipes/vlc/x264_r2245.bb                          |    6 +-
>  2 files changed, 64 insertions(+), 3 deletions(-)
>  create mode 100644 recipes/vlc/x264-r2245/uclibc_log2f_fix.HACK.patch
> 
> diff --git a/recipes/vlc/x264-r2245/uclibc_log2f_fix.HACK.patch b/recipes/vlc/x264-r2245/uclibc_log2f_fix.HACK.patch
> new file mode 100644
> index 0000000..874a0ca
> --- /dev/null
> +++ b/recipes/vlc/x264-r2245/uclibc_log2f_fix.HACK.patch
> @@ -0,0 +1,61 @@
> +diff -Nur x264-snapshot-20100531-2245.vanilla/encoder/analyse.c x264-snapshot-20100531-2245/encoder/analyse.c
> +--- x264-snapshot-20100531-2245.vanilla/encoder/analyse.c	2010-05-31 22:45:11.000000000 +0200
> ++++ x264-snapshot-20100531-2245/encoder/analyse.c	2010-08-20 02:52:11.505161943 +0200
> +@@ -251,7 +251,7 @@
> +     for( int i = 0; i <= 2*4*2048; i++ )
> +     {
> +         h->cost_mv[lambda][-i] =
> +-        h->cost_mv[lambda][i]  = lambda * (log2f(i+1)*2 + 0.718f + !!i) + .5f;
> ++        h->cost_mv[lambda][i]  = lambda * ( (logf(i+1)/logf(2))*2 + 0.718f + !!i) + .5f;
> +     }
> +     x264_pthread_mutex_lock( &cost_ref_mutex );
> +     for( int i = 0; i < 3; i++ )
> +diff -Nur x264-snapshot-20100531-2245.vanilla/encoder/encoder.c x264-snapshot-20100531-2245/encoder/encoder.c
> +--- x264-snapshot-20100531-2245.vanilla/encoder/encoder.c	2010-05-31 22:45:11.000000000 +0200
> ++++ x264-snapshot-20100531-2245/encoder/encoder.c	2010-08-20 02:53:58.516661776 +0200
> +@@ -479,8 +479,8 @@
> +     if( h->param.rc.i_rc_method == X264_RC_CQP )
> +     {
> +         float qp_p = h->param.rc.i_qp_constant;
> +-        float qp_i = qp_p - 6*log2f( h->param.rc.f_ip_factor );
> +-        float qp_b = qp_p + 6*log2f( h->param.rc.f_pb_factor );
> ++        float qp_i = qp_p - 6*(logf(h->param.rc.f_ip_factor)/logf(2));
> ++        float qp_b = qp_p + 6*(logf(h->param.rc.f_pb_factor)/logf(2));
> +         h->param.rc.i_qp_min = x264_clip3( (int)(X264_MIN3( qp_p, qp_i, qp_b )), 0, 51 );
> +         h->param.rc.i_qp_max = x264_clip3( (int)(X264_MAX3( qp_p, qp_i, qp_b ) + .999), 0, 51 );
> +         h->param.rc.i_aq_mode = 0;
> +diff -Nur x264-snapshot-20100531-2245.vanilla/encoder/ratecontrol.c x264-snapshot-20100531-2245/encoder/ratecontrol.c
> +--- x264-snapshot-20100531-2245.vanilla/encoder/ratecontrol.c	2010-05-31 22:45:11.000000000 +0200
> ++++ x264-snapshot-20100531-2245/encoder/ratecontrol.c	2010-08-20 02:55:26.752661912 +0200
> +@@ -549,8 +549,8 @@
> +         rc->last_non_b_pict_type = SLICE_TYPE_I;
> +     }
> + 
> +-    rc->ip_offset = 6.0 * log2f( h->param.rc.f_ip_factor );
> +-    rc->pb_offset = 6.0 * log2f( h->param.rc.f_pb_factor );
> ++    rc->ip_offset = 6.0 * (logf( h->param.rc.f_ip_factor )/logf(2));
> ++    rc->pb_offset = 6.0 * (logf( h->param.rc.f_pb_factor )/logf(2));
> +     rc->qp_constant[SLICE_TYPE_P] = h->param.rc.i_qp_constant;
> +     rc->qp_constant[SLICE_TYPE_I] = x264_clip3( h->param.rc.i_qp_constant - rc->ip_offset + 0.5, 0, 51 );
> +     rc->qp_constant[SLICE_TYPE_B] = x264_clip3( h->param.rc.i_qp_constant + rc->pb_offset + 0.5, 0, 51 );
> +@@ -1154,7 +1154,7 @@
> +             if( zone->b_force_qp )
> +                 q += zone->i_qp - rc->qp_constant[SLICE_TYPE_P];
> +             else
> +-                q -= 6*log2f( zone->f_bitrate_factor );
> ++                q -= 6*(logf( zone->f_bitrate_factor )/logf(2));
> +         }
> +     }
> + 
> +diff -Nur x264-snapshot-20100531-2245.vanilla/encoder/set.c x264-snapshot-20100531-2245/encoder/set.c
> +--- x264-snapshot-20100531-2245.vanilla/encoder/set.c	2010-05-31 22:45:11.000000000 +0200
> ++++ x264-snapshot-20100531-2245/encoder/set.c	2010-08-20 02:58:19.400661820 +0200
> +@@ -234,7 +234,7 @@
> +         sps->vui.i_max_bytes_per_pic_denom = 0;
> +         sps->vui.i_max_bits_per_mb_denom = 0;
> +         sps->vui.i_log2_max_mv_length_horizontal =
> +-        sps->vui.i_log2_max_mv_length_vertical = (int)log2f( X264_MAX( 1, param->analyse.i_mv_range*4-1 ) ) + 1;
> ++        sps->vui.i_log2_max_mv_length_vertical = (int)(logf( X264_MAX( 1, param->analyse.i_mv_range*4-1 ))/logf(2))  + 1;
> +     }
> + }
> + 
> diff --git a/recipes/vlc/x264_r2245.bb b/recipes/vlc/x264_r2245.bb
> index f533bfc..f685c63 100644
> --- a/recipes/vlc/x264_r2245.bb
> +++ b/recipes/vlc/x264_r2245.bb
> @@ -1,10 +1,12 @@
>  DESCRIPTION = "H.264 encoder"
>  LICENSE = "GPL"
> -PR = "r7"
> +PR = "r8"
>  
>  X264PV = "snapshot-20100531-2245"
>  
>  SRC_URI = "http://download.videolan.org/pub/videolan/x264/snapshots/x264-${X264PV}.tar.bz2"
> +SRC_URI_append_libc-uclibc = "file://uclibc_log2f_fix.HACK.patch" 
> +
>  SRC_URI[md5sum] = "d1ccb8122bd418291a9576a2bffdf662"
>  SRC_URI[sha256sum] = "929e946947701a0b3a336a4b9cfe65daf4c52480f45d4363335ae2a3d5596fa9"
>  
> @@ -24,5 +26,3 @@ X264_DISABLE_ASM_x86 = ""
>  DEPENDS_x86 = "yasm-native"
>  
>  EXTRA_OECONF = '--enable-shared ${X264_DISABLE_ASM} --extra-cflags="${X264_ECFLAGS}"'
> -
> -