[v2,2/3] package/mesa3d: bump version to 10.5.1

Dropped several dependencies because the "distribution tarball has been renamed
and now contains all the generated sources."
http://lists.freedesktop.org/archives/mesa-announce/2015-March/000145.html

Signed-off-by: Bernd Kuhls <bernd.kuhls@t-online.de>
---
v2: updated hash (Baruch), added note about dependency changes (Thomas)

 .../0002-Fix-runtime-error-with-uClibc.patch       |   58 ++++++++++++++++++++
 package/mesa3d/mesa3d.hash                         |    4 +-
 package/mesa3d/mesa3d.mk                           |   12 ++--
 3 files changed, 65 insertions(+), 9 deletions(-)
 create mode 100644 package/mesa3d/0002-Fix-runtime-error-with-uClibc.patch

Dear Bernd Kuhls,

On Sun, 15 Mar 2015 17:10:01 +0100, Bernd Kuhls wrote:
> Dropped several dependencies because the "distribution tarball has been renamed
> and now contains all the generated sources."
> http://lists.freedesktop.org/archives/mesa-announce/2015-March/000145.html
> 
> Signed-off-by: Bernd Kuhls <bernd.kuhls@t-online.de>
> ---
> v2: updated hash (Baruch), added note about dependency changes (Thomas)

Thanks for the additional explanation, makes a lot more sense now. I've
applied your patch. I however have a comment:

> ++#ifdef __UCLIBC__
> ++float fmaxf(float a, float b)

This is really a crappy solution. I know we use it in various places,
but it simply does not work properly: if a new version of uClibc is
released with an implementation of fmaxf(), then __UCLIBC__ will still
be true, but we'll have a duplicated implementation of fmaxf().

http://autobuild.buildroot.org/results/6f6/6f62dffec0e299a36755184338524e107a932b16/build-end.log
is an excellent demonstration of why using __UCLIBC__ is bad. This
build failure is caused by the patch
package/freerdp/0001-add-support-for-uclibc.patch, wihch just like
yours adds replacement function if __UCLIBC__ is defined.

Now, enters uClibc-ng, which does implement eventfd_read() and
eventfd_write(), and bang, it fails.

Solution: use a proper autoconf test to see if fmax() is available or
not, or provide an alternate implementation only if it's not already
provided.

Since we're doing this __UCLIBC__ trick in lots of places, I've
nonetheless applied your patch, but it'd be good to use proper
solutions in the future.

Thanks!

Thomas

Dear Bernd Kuhls,

On Sun, 15 Mar 2015 17:10:01 +0100, Bernd Kuhls wrote:

>  MESA3D_DEPENDENCIES = \
>  	expat \
> -	host-bison \
> -	host-flex \
>  	host-gettext \
> -	host-python \
> -	host-xutil_makedepend \
> +	host-python-mako \

This is apparently not working well in some cases, see
http://autobuild.buildroot.net/results/1ce/1ce2509c8abb7483397c7d0f21c299095e94a254/.

Thanks,

Thomas

[posted and mailed]

Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote
in news:20150321095905.0e24d32c@free-electrons.com: 

> This is apparently not working well in some cases, see
> http://autobuild.buildroot.net/results/1ce/1ce2509c8abb7483397c7d0f21c299
> 095e94a254/. 

Hi Thomas,

this seems to be a python2 <-> python3 problem:

$ grep -i "ge_python \|ge_python3=" .config
# BR2_PACKAGE_PYTHON is not set
BR2_PACKAGE_PYTHON3=y

host-python is compiled as

$ ls -la output/build/ | grep host-py
drwxr-xr-x 17 fli4l fli4l  4096 Mär 21 10:48 host-python3-3.4.2
drwxr-xr-x  9 fli4l fli4l  4096 Mär 21 10:48 host-python-mako-1.0.1

but mesa3d checks for python2 first which picks up /usr/bin/python on my
machine 

$ grep PYTHON2 output/build/mesa3d-10.5.1/config.log
ac_cv_prog_PYTHON2=python2
PYTHON2='python2'

due to "AC_CHECK_PROGS([PYTHON2], [python2 python])" in
mesa3d/configure.ac 

Adding

MESA3D_CONF_ENV += ac_cv_prog_PYTHON2=$(HOST_DIR)/usr/bin/python

to mesa3d.mk forcing the usage of host-python3 does not help either:

checking if module mako in python is installed... Traceback (most recent
call last): 
  File "<stdin>", line 10, in <module>
TypeError: unorderable types: map() > map()
configure: error: mako 0.3.4 or later is required.
make: *** [/home/fli4l/br3/output/build/mesa3d-10.5.1/.stamp_configured]
Fehler 1 

Please note that mesa3d does not need the target version of python, only
host-python 2.x. 

Is it possible to compile host-python2 parallel to host-python3 or should
I add a "depends on !BR2_PACKAGE_PYTHON3" to mesa3d/Config.in? 

Regards, Bernd

Thomas Petazzoni <thomas.petazzoni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8
@public.gmane.org> wrote in news:20150317233027.1aee93ce@free-electrons.com:

> Thanks for the additional explanation, makes a lot more sense now. I've
> applied your patch. I however have a comment:
> 
>> ++#ifdef __UCLIBC__
>> ++float fmaxf(float a, float b)
> 
> This is really a crappy solution. I know we use it in various places,
> but it simply does not work properly: if a new version of uClibc is
> released with an implementation of fmaxf(), then __UCLIBC__ will still
> be true, but we'll have a duplicated implementation of fmaxf().

Hi,

uclibc added fmaxf upstream: http://git.uclibc.org/uClibc/commit/?id=
6c4538905e65ceb203f59aaa9a61728e81c6bc0a

mesa3d/0002-Fix-runtime-error-with-uClibc.patch can be removed when the 
forementioned patch is used in buildroot, a local run-time test was positive.
Let´s hope uclibc will make a new release soon ;)

Regards, Bernd