Fixes:
http://autobuild.buildroot.net/results/f72/f72ae17cea910a1dbd3d5d4d09cfbc90d9ba8dc0/
Imports a patch from Alpine Linux to remove __GLIBC__ conditional
compilation. Retested with both musl, glibc and uclibc.
Patch accepted upstream.
Signed-off-by: Brendan Heading <brendanheading@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Fixes:
http://autobuild.buildroot.net/results/3ec/3ec54f722d6008fc422540d3a5462b306d16e84c/
The recent x264 version bump broke the configure step on x86/x86-64 as x264
ends up using gas instead of yasm as assembler. The reason for this is the
recent upstream commit to optionally use nasm instead of yasm if AS= is
passed:
commit b568a256b9bc6c500d7b1ffe4b9c3311ee5ff337
Author: Henrik Gramner <henrik@gramner.com>
Date: Sat May 23 19:44:16 2015 +0200
x86: Experimental nasm support
Enables the use of nasm as an alternative to yasm.
Note that nasm cannot assemble x264 with PIC enabled since it currently doesn't
support [symbol-$$] addressing which is used extensively by x264's PIC code.
This includes all 64-bit Windows and 64-bit OS X builds, even non-shared.
For the above reason nasm is currently intentionally not auto-detected, instead
the assembler must be explicitly specified using "AS=nasm ./configure".
Also drop -O2 from ASFLAGS since it's simply ignored anyway.
But as we pass AS=$(TARGET_AS) it ends up using gas instead. Fix it by
explicitly passing AS=yasm instead.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Fixes
CC dri.lo
/tmp/ccc6IbbW.s: Assembler messages:
/tmp/ccc6IbbW.s:3114: Error: selected processor does not support ARM mode `ldrex r2,[r1]'
/tmp/ccc6IbbW.s:3117: Error: selected processor does not support ARM mode `strexeq r2,r0,[r1]'
/tmp/ccc6IbbW.s:3273: Error: selected processor does not support ARM mode `ldrex r2,[r1]'
/tmp/ccc6IbbW.s:3276: Error: selected processor does not support ARM mode `strexeq r2,r3,[r1]'
/tmp/ccc6IbbW.s:3352: Error: selected processor does not support ARM mode `ldrex r1,[r2]'
/tmp/ccc6IbbW.s:3355: Error: selected processor does not support ARM mode `strexeq r1,r0,[r2]'
/tmp/ccc6IbbW.s:3451: Error: selected processor does not support ARM mode `ldrex r3,[r2]'
/tmp/ccc6IbbW.s:3454: Error: selected processor does not support ARM mode `strexeq r3,ip,[r2]'
/tmp/ccc6IbbW.s:3522: Error: selected processor does not support ARM mode `ldrex r3,[r0]'
/tmp/ccc6IbbW.s:3525: Error: selected processor does not support ARM mode `strexeq r3,r1,[r0]'
Makefile:653: recipe for target 'dri.lo' failed
make[5]: *** [dri.lo] Error 1
make[5]: Leaving directory '/home/buildroot/buildroot/output/build/xserver_xorg-server-1.17.2/hw/xfree86/dri'
using this defconfig
BR2_arm=y
BR2_TOOLCHAIN_BUILDROOT_WCHAR=y
BR2_TOOLCHAIN_BUILDROOT_CXX=y
BR2_ROOTFS_DEVICE_CREATION_DYNAMIC_EUDEV=y
BR2_PACKAGE_MESA3D=y
BR2_PACKAGE_MESA3D_DRI_DRIVER_SWRAST=y
BR2_PACKAGE_XORG7=y
BR2_PACKAGE_XSERVER_XORG_SERVER=y
[Peter: fix conditional, add comment explaining issue]
Signed-off-by: Bernd Kuhls <bernd.kuhls@t-online.de>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Due to recent changes in U-Boot, see
http://git.denx.de/?p=u-boot.git;a=commit;h=a26cd04920dc069fd6e91abb785426cf6c29f45f
re-creation of .config from defconfig by "make oldconfig" happened
incorrectly.
Default prompt for target selection was set as No that lead to missing platform
selection by automated scripts like that:
------------------>8------------------
"yes "" | make oldconfig" on defconfig
------------------>8------------------
And that lead to build failure:
------------------>8------------------
$ make
scripts/kconfig/conf --silentoldconfig Kconfig
CHK include/config.h
UPD include/config.h
GEN include/autoconf.mk
In file included from ./include/common.h:18:0:
include/config.h:5:22: fatal error: configs/.h: No such file or directory
#include <configs/.h>
^
compilation terminated.
scripts/Makefile.autoconf:72: recipe for target 'include/autoconf.mk' failed
make[1]: *** [include/autoconf.mk] Error 1
------------------>8------------------
This patch reverts mentioned change making possible to build U-Boot
2015.07 in Buildroot.
Note there's a probability that this particular patch won't make its way
in upstream U-Boot and better solution will be found there. But for now
we need to fix U-Boot building in Buildroot anyways.
Hopefully for the next release this patch won't be necessary.
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
When the rootfs is read-only, keys will be generated in a volatile
location, which is inherently bad as host keys will change on each boot,
rendering them virtually useless.
Add a warning so the user is at least aware of the issue.
Hide the rm output to avoid noisy output, now that we have a proper warning.
Move the starting message after the symlink-block, to avoid messages
collision. Move the umask as well, since /etc/dropbear/ may be world
readable; just the private host keys should be ?00 (and dropbear handles
that by itself).
[Peter: minor tweaks to commit message]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Peter Korsgaard <jacmet@uclibc.org>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
X.org xserver depends on libepoxy for glamor support, which depends on
EGL support. Mesa3d is not the only possible EGL provider therefore
change the dependency check.
Signed-off-by: Bernd Kuhls <bernd.kuhls@t-online.de>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Even though setools itself does not require wide chars, the configure
script needs them when testing for C99 support.
Since:
- it is not clear whether wchar are mandatory for C99 or not,
- only uClibc may miss support for wide chars,
- using SELinux would probably involve rather big systems (i.e. glibc
would not be such a huge overhead),
just make setools depend on the toolchain having widechar.
Fixes:
http://autobuild.buildroot.org/results/051/051a7f72ebadd56407700c22b57e942f08eb1c09/http://autobuild.buildroot.org/results/a4b/a4b2a6f1920430af43c23239de17200e70951b3b/
...
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Matt Weber <matthew.weber@rockwellcollins.com>
Cc: Clayton Shotwell <clayton.shotwell@rockwellcollins.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Like Romain Naour did for util-linux, this commit adds a patch for the
ipkg package to remove the use of the __P, which is useless for modern
compilers, and not defined by the musl C library.
Fixes:
http://autobuild.buildroot.net/results/c27d1d1e6a9bb52fead7b48625bb456f42b2f056/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Recently, we've tried to have the manual lie at the top-level of the
site, to get a shorter URL.
However, that is broken: we do not need only a link the the HTML, but
also to the CSS and to any resource linked from the html (images...).
The server configuration has now been updated to add a redirect, so we
no longer need that symlink anyway. Remove it.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Peter Korsgaard <jacmet@uclibc.org>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Because of a limitation in how makedevs resolves names [0], usernames
and groupnames would be resolved with UIDs and GIDs from the host, not
the target.
Fixing makedevs would involve us rewriting a /etc/passwd and /etc/group
parser (not too complex, still not trivial).
Document that the user and group fields should only be numbers, not
names. Also, the manual is currently misleading, as an example indeed
uses names for the user and group fields. Fix that and expand the
explanations.
The mode field should also be numbers, not a rwx combo.
Slight typographical eye-candy about major/minor fields.
[0] it uses getpwnma(3) and getgrnam(3) to resolve names to IDs, and
those only resolve names on the host (i.e. there is no way to specify
a chroot-like feature)
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Building with ccache failed with:
Running configuration tests...
Failed to process makespec for platform 'devices/linux-buildroot-g++'
Project ERROR: Compiler <path_to_output_dir>/host/usr/bin/ccache <path_to_output_dir>/host/usr/bin/<cross_compile>-g++ not found. Check the value of CROSS_COMPILE -device-option
Could not read qmake configuration file <path_to_output_dir>/build/qt5base-5.5.0/mkspecs/devices/linux-buildroot-g++/qmake.conf.
Error processing project file: /dev/null
This was caused by Buildroot setting this in
qt5base-5.5.0/mkspecs/devices/linux-buildroot-g++/qmake.conf:
QMAKE_CXX = $${BR_CCACHE} $${CROSS_COMPILE}g++
But qt5base-5.5.0/mkspecs/features/device_config.prf expects QMAKE_CXX
to be a single valid (absolute or QMAKE_PATH_ENV-relative) path to an
existing file, which is not possible if using ccache as above.
Add a patch fixing this by testing only the first value in QMAKE_CXX.
Signed-off-by: Benoît Thébaudeau <benoit@wsystem.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
When using the python-package infrastructure, there is no need for
packages to declare a dependency on the Python interpreter: the
package infrastructure does it automatically.
Moreover, this is actually broken in the case of python-can, which can
be selected either with Python 2.x or Python 3.x. If the latter is
chosen, python-can will still trigger the build of Python 2.x, which
is incorrect.
This was discovered by Vicente Olivert Riera during the analysis of
the following build failure:
http://autobuild.buildroot.net/results/aff/affb1d4a328c479be73b7818364db5914bf3d376/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Fix the missing gstreamer1 build dependencies, which could possibly
prevent the configuration of qt5multimedia from detecting the supported
gstreamer1 features.
Fix the missing gstreamer1 install rules, which resulted in the
following runtime error:
defaultServiceProvider::requestService(): no service found for - "org.qt-project.qt.mediaplayer"
Signed-off-by: Benoît Thébaudeau <benoit@wsystem.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Even though we have some specific code to support building Qt5 for
static-only configurations, it doesn't work. The first problem is that
our custom qmake.conf always passes -ldl, which makes a number of Qt5
config.tests fail at configure time. Once this problem is fixed by
removing -ldl from QMAKE_LIBS and adding it to QMAKE_LIBS_DYNLOAD
instead, the next problem is that the plugin infrastructure of Qt5
assumes that Linux has dynamic library support: the qlibrary_unix.cpp
file includes <dlfcn.h>, and the only condition for this file to not
be included is:
Until recently, building Qt5 statically was working because our C
library was not built static-only: it provided <dlfcn.h> and
libdl.so. But now that we have a really static only toolchain, Qt5 no
longer builds.
The easiest solution is to simply make Qt5 depend on dynamic library
support.
Fixes:
http://autobuild.buildroot.net/results/538/538e0325adba9fabbe4ec8e550fbb6a7219f5e7a/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
It should point to the filesystem path on the server, not the HTTP virtual path.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
This will give us a shorter URL, that we can more easily refer to in the
documetation itself, in help texts, on IRC...
[Peter: Use buildroot.org everywhere]
Suggested-by: Arnout Vandecappelle <arnout@mind.be>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Arnout Vandecappelle <arnout@mind.be>
Cc: Peter Korsgaard <jacmet@uclibc.org>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Fixes: http://autobuild.buildroot.net/results/e33/e337d69420ad00b2cc4017d639a31803926f2353/
linux-pam needs some surgery to build under musl, so for the time being
disable it until the issues are solved. Also disables dependent package
python-pam, and dependent suboptions under openvmtools, rsh-redone and
util-linux.
Signed-off-by: Brendan Heading <brendanheading@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The last tagged release of zyre, v1.0.0, was made in May 2014. Since
then, they have switched to pkg-config to detect zmq and czmq, which
fixes static linking problems. However, they made a number of changes
to configure.ac, which make it difficult to backport just the relevant
changes.
Since we already had another backported fix, let's simply bump the
version of zyre to the latest available commit, which builds fine with
no change for shared and static scenarios, thanks to the use of
pkg-config.
An issue was opened upstream to ask them to tag a new release:
https://github.com/zeromq/zyre/issues/324.
Fixes:
http://autobuild.buildroot.net/results/0ab/0ab4c6a4bb4942d51e7712073d4731d81ecb5251/
Thanks to Vincente Olivert Riera for the initial investigation.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Fixes:
CVE-2015-6563 - Fixed a privilege separation weakness related to PAM
support.
CVE-2015-6564 - Fixed a use-after-free bug related to PAM support that
was reachable by attackers who could compromise the pre-authentication
process for remote code exectuion.
CVE-2015-6565 - incorrectly set TTYs to be world-writable.
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Currently libunwind support in ltrace is broken for MIPS. I'm working
with upstream to fix this issue, but it's not yet ready, so let's
disable it by now.
Fixes:
http://autobuild.buildroot.net/results/79b/79b51941ed57b0564c68112489b03cac39a04e9a/
Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The Makefiles for canfestival are not correctly written, which leads to
multiple warnings such as:
make[4]: warning: jobserver unavailable: using -j1. Add `+' to parent make rule.
Since canfestival is relatively small, it builds in less than 6s here
when not in parallell, while a parallel build takes 5s.
Just disable parallel build to avoid future surprises.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
libmbim uses code (originally from udev) that has since been split
from the main systemd codebase into libgudev.
Fixes: http://autobuild.buildroot.org/results/638/638dbf05b785a276a33983b0237b7cad54777b85/
Tweak the package files for libmbim to require libgudev when building
with systemd.
Signed-off-by: Nathaniel Roach <nroach44@gmail.com>
Tested-by: Yegor Yefremov <yegorslists@googlemail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
NetworkManager uses code (originally from udev) that has since been
split from the main systemd codebase into libgudev.
Tweak the package files for NetworkManager to require libgudev when
building with systemd.
Signed-off-by: Nathaniel Roach <nroach44@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
As libgudev recently was split from the main systemd/udev source, this
library is now required to build certain packages.
This library is only relevant to systemd, as the code it contains is
still contained in eudev.
[Thomas:
- don't show the dependency comment when systemd is not available,
since libgudev is anyway useless when you're not using systemd.
- fix the license, it's LGPLv2.1+ and not GPLv2+
- remove useless empty lines in the .mk file.]
Signed-off-by: Nathaniel Roach <nroach44@gmail.com>
Tested-by: Yegor Yefremov <yegorslists@googlemail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Currently, the configurators are using $($(2)_MAKE_ENV), often derived
from $(TARGE_MAKE_ENV), as the environment to be set when calling the
various configurators.
This means that our host tools are used first, most notably pkg-config
(from host-pkgconf).
However, this is inherently flawed. Our pkg-config, when set for the
host, only searches .pc files in $(HOST_DIR) and never ever uses the
ones from the host. For example, since we do not build a host-qt, our
pkg-config would not find the host's QtCore.pc et al.
Consequently, on some systems (but not on others?) most of the
configurators fail to build, especially the latest kernel versions, as
they have been starting to use pkg-config two years ago.
Fix that by filtering-out sensible values out of the environment, but
only when calling the configurators.
[Thomas: rewrap comment to appropriate length.]
Reported-by: Mauro Condarelli <mc5686@mclink.it>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Mauro Condarelli <mc5686@mclink.it>
Tested-by: Mauro Condarelli <mc5686@mclink.it>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Fixes compile error using this defconfig
BR2_TOOLCHAIN_BUILDROOT_WCHAR=y
BR2_TOOLCHAIN_BUILDROOT_CXX=y
BR2_PACKAGE_XORG7=y
BR2_PACKAGE_XSERVER_XORG_SERVER=y
BR2_PACKAGE_XPROTO_DRI2PROTO=y
drmVersionPtr is referenced not only in hw/xfree86/dri2/dri2.c
but also in hw/xfree86/dri/dri.c.
Signed-off-by: Bernd Kuhls <bernd.kuhls@t-online.de>
Reviewed-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Tested-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
vlc supports both opencv-2.4 and opencv-3, so adjust the vlc package to
reflect this.
Cc: Jonathan Ben Avraham <yba@tkos.co.il>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Samuel Martin <s.martin49@gmail.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
This (partially) reverts commit 5e238a87ea.
The dependency is changed from a 'select' to a 'depends on' to avoid a
circular dependency caused by the introduction of OpenCV-3. This means
we can also drop the threads and C++ dependencies, since they are now
inherited via the depends on OpenCV.
Cc: Jonathan Ben Avraham <yba@tkos.co.il>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Samuel Martin <s.martin49@gmail.com>
[yann.morin.1998@free.fr: fix dependencies]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
As Jonathan noticed in [1], users' applications may depend on opencv-2.4
APIs removed in opencv-3.0.
So, re-introduce opencv package as it was right before the bump to
opencv-3.0 (i.e.: commit bf00b5a9ea).
We do not support both OpenCV-2.4 and OpenCV-3 at the same time, so make
OpenCV-3 depend on !OpenCV-2.4.
[1] http://lists.busybox.net/pipermail/buildroot/2015-August/135270.html
Cc: Jonathan Ben Avraham <yba@tkos.co.il>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Samuel Martin <s.martin49@gmail.com>
[yann.morin.1998@free.fr:
- remove legacy symbols, now
- make opencv3 depends on !opencv, not the other way around
- slitghly reword the commit log (opencv/opencv3 dependency)
]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
