mesa3d configure triggers the _gp bug:
http://autobuild.buildroot.net/results/8be/8be577dae511f82d45ab3b0a9bba370b81ad2ff9//mesa3d-10.6.1/config.log
/home/test/autobuild/instance-1/output/host/opt/ext-toolchain/bin/../lib/gcc/nios2-linux-gnu/4.8.3/../../../../nios2-linux-gnu/bin/ld: /home/test/autobuild/instance-1/output/host/usr/nios2-buildroot-linux-gnu/sysroot/usr/lib/crt1.o: undefined reference to symbol '_gp'
/home/test/autobuild/instance-1/output/host/usr/nios2-buildroot-linux-gnu/sysroot/usr/lib/libgpg-error.so.0: error adding symbols: DSO missing from command line
Fixes
http://autobuild.buildroot.net/results/8be/8be577dae511f82d45ab3b0a9bba370b81ad2ff9/
[Thomas: propagate the dependency to mesa3d comment about toolchain
dependencies.]
Signed-off-by: Bernd Kuhls <bernd.kuhls@t-online.de>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Mesa3d 10.6 adds optional support for SHA-1:
http://cgit.freedesktop.org/mesa/mesa/commit/configure.ac?id=a24bdce46f95cbe9efd3b26f157d1eb36584861f
Adding "--without-sha1" will cause this failure during configure:
configure: error: Illegal value for --with-sha1: no
so I did not add the else-clause when no SHA-1 provider is enabled.
[Thomas: simplify else ifeq.]
Signed-off-by: Bernd Kuhls <bernd.kuhls@t-online.de>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Thus, it is possible to force compilation of Gallium/DRI support in
mesa3d even if no Gallium/DRI drivers are selected. This is intended to
be used by external OpenGL provider (especialy further imx6 support).
Signed-off-by: Jérôme Pouiller <jezz@sysmic.org>
Reviewed-by: Bernd Kuhls <bernd.kuhls@t-online.de>
Tested-by: Gary Bisson <gary.bisson@boundarydevices.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Now that largefile is mandatory removes package dependencies and
conditionals.
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
When it's not defined an automatic search is triggered, which can find
/usr/bin/llvm-config on distributions that include all development files
(like gentoo) and have desktop packages installed.
So point it towards the staging dir which is where it should live
eventually if/when we've got it to avoid header/include path polution
that otherwise leads to build failures.
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
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>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Some OpenGL/EGL/GLES/VG providers do not provide the corresponding
headers, and rely on using "the headers provided by the distribution".
In our case, we can not rely on such headers, because we are not a
distribution, and we have no way to provide those headers (not even
speaking about relying on the headers provided by hte host distribution,
because they might well not be installed at all).
Also, we can not rely on another package to provide those headers,
because we can only have one provider enabled in any configuration.
The Khronos group provides such headers, and they are the reference
headers, but we can not realy use them:
- most of them are not packaged: they are not versioned and not
provided in a tarball, but as separately downloadable files;
- those headers are anyway incomplete: there are headers not provided
by Khronos, like GL.h
Instead, we rely on mesa3d to provide those headers: mesa3d has all the
headers we need.
Modifying the existing mesa3d package would not be easy; we'd have to
differentiate whther we need only the headers or the full package. The
meas3d Config.in and .mk are already quite non-trivial that adding such
a feature would render them even more illegible.
So, we introduce mea3d-headers as a new package, that is in fact just
mesa3d with a much simplified Config.in and .mk, that other OpenXXX
providers may select if they do not provide the OpenXXX headers.
Note: we're not installing GLES3 headers, because what Buildroot
currently calls libgles is in fact libgles2; we have no way to specify
that we have libgles3. So, we just install headers for GLES and GLES2.
[Thomas:
- Wrap Config.in help text to a reasonable length.
- Don't rely on mesa3d to provide mesa3d-headers: they should be
mutually exclusive. Instead, error out if both packages are
selected.
- Take into account the update of mesa3d to 10.4.5.
- Don't copy each header file individually, use a cp -dpfr call to
copy entires header files directories.]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
--
v2: - rebased patch from micro1183: http://patchwork.ozlabs.org/patch/398858/
- removed support for r300 & radeonsi because they need llvm support
which is not provided by buildroot
Signed-off-by: Bernd Kuhls <bernd.kuhls@t-online.de>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Thanks to commit 2dde40081c
("package/mesa3d: Refactor XA support to prepare support for ATI
drivers"), we now have the blind option BR2_PACKAGE_MESA3D_NEEDS_XA
that indicates whether XA support is needed. This allows to switch to
use positive logic in the test for XA in mesa3d.mk, which this commit
does.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
[Thomas:
- move the new blind option next to the other existing blind options
in the package.
- edit the commit log to remove the changelog.]
Signed-off-by: Bernd Kuhls <bernd.kuhls@t-online.de>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Since a while, the semantic of BR2_PREFER_STATIC_LIB has been changed
from "prefer static libraries when possible" to "use only static
libraries". The former semantic didn't make much sense, since the user
had absolutely no control/idea of which package would use static
libraries, and which packages would not. Therefore, for quite some
time, we have been starting to enforce that BR2_PREFER_STATIC_LIB
should really build everything with static libraries.
As a consequence, this patch renames BR2_PREFER_STATIC_LIB to
BR2_STATIC_LIBS, and adjust the Config.in option accordingly.
This also helps preparing the addition of other options to select
shared, shared+static or just static.
Note that we have verified that this commit can be reproduced by
simply doing a global rename of BR2_PREFER_STATIC_LIB to
BR2_STATIC_LIBS plus adding BR2_PREFER_STATIC_LIB to Config.in.legacy.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
To be consistent with the recent change of FOO_MAKE_OPT into FOO_MAKE_OPTS,
make the same change for FOO_CONF_OPT.
Sed command used:
find * -type f | xargs sed -i 's#_CONF_OPT\>#&S#g'
Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
If no dri drivers are enabled, then mesa shouldn't get built with dri
support.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Acked-by: Bernd Kuhls <bernd.kuhls@t-online.de>
xlib_libXxf86vm is an optional dependency for the DRI drivers,
quote from mesa3d/configure.ac:
# add xf86vidmode if available
PKG_CHECK_MODULES([XF86VIDMODE], [xxf86vm], HAVE_XF86VIDMODE=yes, HAVE_XF86VIDMODE=no)
if test "$HAVE_XF86VIDMODE" = yes ; then
dri_modules="$dri_modules xxf86vm"
fi
Add the package as an optional dependency to have reproducable builds.
Signed-off-by: Bernd Kuhls <bernd.kuhls@t-online.de>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The help entry for the i965 DRI driver states that it supports alll
Intel GPUs. That's not true, as at least the i915 series is not handled
by this driver, but by a separate one.
Fix the help text accordingly; remove the useless second part of the
help text (which does not mean much for Buildroot.)
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
