They're not necessary and look bad.
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Many lines are not correctly wrapped to 72 column width, so rewrap them.
In addition, standardize all instances of ". " to ". ".
Signed-off-by: Martin Kelly <martin@surround.io>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Add support for EXT4 filesystem.
Signed-off-by: Fabio Estevam <festevam@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Update U-boot to the 2016.05 version and the kernel to 4.6.
U-boot 2016.05 needs the patch c510f2e436008 ("video: ipu_common: fix build
error") that is already in mainline to fix an IPU build error.
We can remove this patch in the future when we switch to U-boot 2016.07.
Signed-off-by: Fabio Estevam <festevam@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
mesa3d doesn't like the new compressed exception handling of the Code
Sourcery MIPS toolchain and it fails to compile with an error like this
one:
/br/output/host/opt/ext-toolchain/bin/../lib/gcc/mips-linux-gnu/5.3.0/../../../../mips-linux-gnu/bin/ld:
../../../../src/mesa/.libs/libmesagallium.a(ir_to_mesa.o):
.eh_frame_entry not in order
/br/output/host/opt/ext-toolchain/bin/../lib/gcc/mips-linux-gnu/5.3.0/../../../../mips-linux-gnu/bin/ld:
final link failed: Nonrepresentable section on output
collect2: error: ld returned 1 exit status
Using -mno-compact-eh fixes the problem.
Fixes:
http://autobuild.buildroot.net/results/3cd/3cd81c57c51c0963ee6f4d9b814989460bb35316/
Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
[Thomas: improve comment in code.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Fixes:
CVE-2015-8872 - if the third to last entry was written on a FAT12
filesystem with an odd number of clusters, the second to last entry
would be corrupted. This corruption may also lead to invalid memory
accesses when the corrupted entry becomes out of bounds and is used
late.
CVE-2016-4804 - the variable used for storing the FAT size (in bytes)
was an unsigned int. Since the size in sectors read from the BPB was not
sufficiently checked, this could end up being zero after multiplying it
with the sector size while some offsets still stayed excessive.
Ultimately it would cause segfaults when accessing FAT entries for which
no memory was allocated.
Converted package to autotools infra to match upstream.
The install options are now removals, enabled compatibilty symlinks and
exec-prefix set to / to match previous install names/locations.
Accounted for optional udev usage.
Dropped musl compatibility patch since it's upstream.
Add upstream patch to keep sectors a multiple of sectors per track since
it makes mtools cranky.
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
When net-tools are build with uClibc-ng and statically linked,
some tools like hostname and route needs to link with -lintl.
Adding -lintl in LDFLAGS place the library before object files:
arm-linux-gcc -O2 -g -Wall -fno-strict-aliasing -static -lintl -Llib -o hostname hostname.o
Add $(LIBS) after object files in the Makefile to place -lintl correctly.
Rework NET_TOOLS_BUILD_CMDS to set LDFLAGS with only TARGET_LDFLAGS and
set LIBS with -lintl when needed.
Fixes:
http://autobuild.buildroot.net/results/134/1345b6d366125320b89512e7ce7f142f1a03acf8
Ref:
http://lists.busybox.net/pipermail/buildroot/2016-May/162216.html
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
In 2a87b64 (toolchain-external: align library locations in target and
staging dir), copying the libraries from the sysroot to the target was
changed to a simple find-based solution.
To be sure that the staging directory was entered to find the libraries,
in case the variable was pointing to a symlink, the -L clause to find
was used.
However, that causes extraneous libraries to be copied over.
For example, a ct-ng toolchain would have this sysroot (e.g for an arm
32-bit toolchain):
.../sysroot/lib/
.../sysroot/lib32 -> lib
.../sysroot/lib64 -> lib
.../sysroot/usr/lib/
.../sysroot/usr/lib32 -> lib
.../sysroot/usr/lib64 -> lib
Which we would carry as-is to our own sysroot.
But then, in target, our skeleton creates the /lib/ and /usr/lib
directories, with the necessary lib32 or lib64 symlink pointing to it.
In this case, a lib32->lib symlink is created, but no lib64 symlink
since this is a 32-bit architecture.
To copy the required libraries from staging into target, we scan the
staging directory for all occurences of the required libraries, and copy
them over to target, keeping the same directory layout relative to the
sysroot.
For example:
.../sysroot/usr/lib/libfoo.so --> .../target/usr/lib/libfoo.so
.../sysroot/usr/lib32/libbar.so --> .../target/usr/lib32/libbar.so
.../sysroot/usr/lib64/libbuz.so --> .../target/usr/lib64/libbuz.so
So, when we copy over the libraries from our staging to the target
directory, the "find -L .../sysroot -name libblabla.so.*" would find
multiple instances of libblabla, each in the /usr/lib /usr/lib32 and
/usr/lib64 locations (they are all the exact same file, though).
Since we do have the /usr/lib32->lib symlink, all is OK (but there are
two copies going on, which could be avoided). However, since we do not
have the /usr/lib64->lib symlink, the /usr/lib64/ directory is created.
This was very difficult to observe, as no /lib64/ directory is created,
only the /usr/lib64/ one was. To top it off, this only happens with a
merged /usr, which does not seem like not a common case without systemd.
Since the reason to use -L was to be sure to enter our staging
directory, we just need to ensure that the path ends up with a slash, as
was already talked about in this thread:
http://lists.busybox.net/pipermail/buildroot/2016-April/159737.html
After further discussion, it turns out that the original patch came along
because of the confusion between output/staging (which is a symlink) and
$(STAGING_DIR) which expands to output/host/usr/<tupple>/sysroot (which is
never a symlink), so the symlink handling isn't really needed at all.
[Peter: drop description comment, extend description]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Arnout Vandecappelle <arnout@mind.be>
Cc: Thomas De Schampheleire <patrickdepinguin@gmail.com>
Cc: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Compilation triggers an ICE in gcc with gcc 4.9
../db/dist/../lock/lock_deadlock.c: In function '__lock_detect_rpmdb':
../db/dist/../lock/lock_deadlock.c:354:1: internal compiler error: Segmentation fault
}
^
using this defconfig
BR2_sh=y
BR2_TOOLCHAIN_BUILDROOT_WCHAR=y
BR2_PACKAGE_BUSYBOX_SHOW_OTHERS=y
BR2_PACKAGE_RPM=y
Compiling rpm with gcc5 works fine using this defconfig:
BR2_sh=y
BR2_TOOLCHAIN_BUILDROOT_WCHAR=y
BR2_GCC_VERSION_5_X=y
BR2_PACKAGE_BUSYBOX_SHOW_OTHERS=y
BR2_PACKAGE_RPM=y
This patch adds a dependency to gcc >= 5.x to fix
http://autobuild.buildroot.net/results/e4b/e4b7705e3e148755ae34d498c860a3b9b915e0b0/
[Peter: simpify kconfig, add comment explaining why]
Signed-off-by: Bernd Kuhls <bernd.kuhls@t-online.de>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Compilation triggers an ICE in gcc with gcc <= 4.9 using this defconfig
BR2_sh=y
BR2_TOOLCHAIN_BUILDROOT_WCHAR=y
BR2_PACKAGE_GSTREAMER=y
BR2_PACKAGE_GST_FFMPEG=y
BR2_PACKAGE_GST_FFMPEG_GPL=y
The problem is known upstream, a fix was never committed to gcc <= 4.9:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65151
Compiling gst-ffmpeg with gcc5 works fine using this defconfig:
BR2_sh=y
BR2_TOOLCHAIN_BUILDROOT_WCHAR=y
BR2_GCC_VERSION_5_X=y
BR2_PACKAGE_GSTREAMER=y
BR2_PACKAGE_GST_FFMPEG=y
BR2_PACKAGE_GST_FFMPEG_GPL=y
This patch adds a dependency to gcc >= 5.x to fix the problem as
suggested by Thomas:
http://lists.busybox.net/pipermail/buildroot/2016-February/152584.html
Fixes
http://autobuild.buildroot.net/results/939/939da0c7771ddd97c05cedc0a7afc0ad34a21312/
[Peter: fix ML link, simplify kconfig, add comment explaining why]
Signed-off-by: Bernd Kuhls <bernd.kuhls@t-online.de>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Free software library that interfaces with selected Z-Wave PC
controllers, allowing anyone to create applications that manipulate and
respond to devices on a Z-Wave network, without requiring in-depth
knowledge of the Z-Wave protocol
[Peter: also pass DOXYGEN=, add _MAKE_OPTS and use for build+install]
Signed-off-by: Fabrice Fontaine <fabrice.fontaine@orange.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
With some toolchains, using atomics requires to explicitly add -latomic
to the linker flags.
This change adds a patch to pulseview adding this detection and updating
the LDFLAGS when appropriate.
This patch has be sent upstream:
http://article.gmane.org/gmane.comp.debugging.sigrok.devel/2097
Fixes:
http://autobuild.buildroot.org/results/1e3/1e3101261252d5f30fdf842cc99604e4f4c25eef/build-end.log
Cc: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Cc: Romain Naour <romain.naour@gmail.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Samuel Martin <s.martin49@gmail.com>
Reviewed-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
This commit improves the handling of the "atomic stuff" in the libdrm
package. libdrm can either use the atomic intrinsics (4 byte variant)
when available, or otherwise can use libatomic_ops. Note that the
dependency on atomic operations is not from libdrm itself, but only
from some specific DRM drivers only.
Amongst other things, it fixes the build of the libdrm package on
SPARCv8, therefore fixing:
http://autobuild.buildroot.org/results/74dd29b5ea146c320fde80a87a2fc910de9b7f60/
This commit does a number of changes that are all related to each
other:
- Removes the dependency of the Intel DRM driver on
libatomic_ops. The Intel DRM driver builds perfectly fine without
libatomic_ops, as long as 4-byte variant __sync operations are
available, which is always the case on x86 and x86_84 (which are
the only architectures on which the Intel DRM driver can be
enabled).
- Adds an hidden Config.in boolean option
BR2_PACKAGE_LIBDRM_HAS_ATOMIC that allows DRM driver that need
atomic operation to know whether atomic support is available
(either through intrinsics or through libatomic_ops).
- Adds an hidden BR2_PACKAGE_LIBDRM_ENABLE_ATOMIC Config.in option
that DRM drivers that need atomic operation should select to ensure
that the relevant dependencies are selected. It simply selects
libatomic_ops if 4-byte atomic intrinsics are not available. We
could let each DRM driver do this, but having an intermediate
option avoids a bit of duplication.
- Adds a patch that defines AO_REQUIRE_CAS before including
<atomic_ops.h>. This is needed because libdrm uses the
AO_compare_and_swap_full() which is only provided on all
architectures when AO_REQUIRE_CAS is defined. The exact same fix
was done in the erlang package in commit
4a9df29424.
- Adds the dependency on libatomic_ops when the package is enabled,
and passes the necessary CFLAGS on SPARCv8 to make the thing build
properly. The same CFLAGS are passed in the nginx package and bdwgc
package.
Cc: Waldemar Brodkorb <wbx@openadk.org>
Cc: Bernd Kuhls <bernd.kuhls@t-online.de>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
This is basically the same change as in 0515fe4566
("Makefile: pass host PKG_CONFIG_PATH at "make menuconfig" time"). That
commit made sure to pass host PKG_CONFIG_PATH when invoking Buildroot's
own menuconfig program. This change ensures that the same is true for
third party menuconfig programs (i.e. Linux, uClibc and Busybox).
This unbreaks "make {linux,uclibc}-menuconfig" for host platforms which
rely on PKG_CONFIG_PATH to find .pc files (e.g. NixOS). (When Busybox
updates to a more recent Kconfig snapshot, one that uses pkg-config to
find ncurses, "make busybox-menuconfig" will also start working.)
Tested on Ubuntu and NixOS:
$ make qemu_arm_versatile_defconfig
$ make linux-menuconfig
$ make
Signed-off-by: Bjørn Forsman <bjorn.forsman@gmail.com>
Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
This package introduces batman-adv, a kernel module implementation of
the B.A.T.M.A.N. IV and V mesh network routing protocols.
While batman-adv exists in the mainline kernel tree, it can also be
built as an external out-of-tree module. This package adds the
flexibility to chose a more up to date version of the module than exists
in the official tree, and also allows for compilation against kernels
without batman-adv in-tree support.
https://www.open-mesh.org/projects/batman-adv/
Signed-off-by: Christian Stewart <christian@paral.in>
[Thomas:
- remove "default n", since it's the default
- fix indentation of Config.in help text
- license is GPLv2, not just GPL
- remove variable BATMAN_ADV_MAKE_OPTS, name it directly
BATMAN_ADV_MODULE_MAKE_OPTS as this is what is expected by the kernel
module infrastructure.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Bump batctl to the latest (2016.1) from 2015.1.
Signed-off-by: Christian Stewart <christian@paral.in>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
__P() is used for compatibility with old K&R C compilers. With
ANSI C this macro has no effect.
Unlike for util-linux and ipkg packages where it was easy to remove
each __P() macro, ipsec-tools use it all over the tree and require a
"big" patch to enable musl support.
Since upstream seems not verry active (last release 2014-02-27)
So, disable ipsec-tools with musl based toolchains.
This fixes a compilation error with musl libc because of undeclared
__P.
Fixes:
http://autobuild.buildroot.net/results/42242e3f4485b9e77a916e6fe480c83f70e024e4
While at it, reorder "depends on" and "select" lines in Config.in
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
When iptraf-ng is build with musl, it needs _GNU_SOURCE in CFLAGS to define
the content of "struct tcphdr".
iptraf-ng.mk try to add _GNU_SOURCE in CFLAGS but it's not taken into account.
Add it using IPTRAF_NG_CONF_ENV instead of IPTRAF_NG_MAKE_ENV.
Fixes:
http://autobuild.buildroot.net/results/a1b/a1b18f2e3d075d349c19536a7c5553f24b75a323
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Commit 5c67cb1d04 ("linux: use zImage by default on ARM") changed
the default kernel image, but missed to update Zynq defconfigs.
U-Boot on Zynq boards still loads uImage, so BR2_LINUX_KERNEL_UIMAGE
should be defined to generate uImage.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Generate a valid configuration for architectures with
FDPIC and BFLT support.
Signed-off-by: Waldemar Brodkorb <wbx@openadk.org>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Added upstream commit to fix compilation when zlib is missing.
Signed-off-by: Bernd Kuhls <bernd.kuhls@t-online.de>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
It can be a little bit misleading to have no init system...
Add a comment that states the user has to provide his own init system,
either via a package or a rootfs overlay.
It is expected that such a user will know what to provide, so we don't
really need to specify that it should be /init or /sbin/init or any
arbitrary executable pointed to by the kernel command line "init=..."
or anything else...
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Removed 0001-cmake-use-the-standard-CMake-flag-to-drive-the-share.patch,
a similar patch was committed upstream:
ea55c8b5c1
Also remove empty line from Config.in.
Signed-off-by: Bernd Kuhls <bernd.kuhls@t-online.de>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The mplayer configure script tries to detect the capabilities of the CPU
used by probing the host CPU. This leads to compilation failures if the
target CPU has lesser features, like missing mmx support for
BR2_x86_i686=y:
Checking for CPU vendor ... GenuineIntel (6:58:9)
Checking for CPU type ... Intel(R) Core(TM) i7-3770S CPU @ 3.10GHz
Checking for kernel support of sse ... yes
Checking for kernel support of sse2 ... yes
Checking for kernel support of sse3 ... yes
Checking for kernel support of ssse3 ... yes
Checking for kernel support of sse4_1 ... yes
Checking for kernel support of sse4_2 ... yes
Checking for kernel support of avx ... yes
For this patch I copied most of ffmpeg configure options for x86 CPUs
because mplayer contains its own copy of ffmpeg.
Fixes
http://autobuild.buildroot.net/results/c5a/c5a722607ec9797c317b63b0fd3235608a340c98/
Signed-off-by: Bernd Kuhls <bernd.kuhls@t-online.de>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
It may be useful in some scenarios and size growth is marginal at best.
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
