Baruch Siach [Sun, 13 May 2018 18:37:59 +0000 (21:37 +0300)]
libkrb5: disable rpath
The default rpath value for krb5 is /usr/lib. On some hosts this might
confuse the build time linker as it looks for target libraries in the
host /usr/lib directory.
Yann E. MORIN [Sun, 13 May 2018 16:59:23 +0000 (18:59 +0200)]
package/xen: force location of init scripts
The Xen configure scripts looks at the build host to decide where to
install the Sys-V startup scripts, and that location differs between
various distros.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Matt Weber <matthew.weber@rockwellcollins.com> Cc: Alistair Francis <alistair@alistair23.me> Reviewed-by: Alistair Francis <alistair@alistair23.me> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
If BR2_SHARED_LIBS is set, only install shared version of library
(continue to build both libraries through all target as there is no
libcap.so target but only a libcap.so.$(VERSION).$(MINOR))
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Bernd Kuhls [Wed, 9 May 2018 19:34:16 +0000 (21:34 +0200)]
package/apr-util: fix ldap detection
configure checks if ldap_set_rebind_proc takes 2 or 3 arguments
http://svn.apache.org/viewvc/apr/apr-util/tags/1.6.1/build/apu-conf.m4?revision=1812528&view=markup#l370
It uses the macro APR_TRY_COMPILE_NO_WARNING which adds -Werror to
treat all warnings as errors when gcc is used:
http://svn.apache.org/viewvc/apr/apr/tags/1.6.3/build/apr_common.m4?revision=1812527&view=markup#l504
In some buildroot configs a compiler warning occurs during this check:
http://autobuild.buildroot.net/results/241/241ed78b93ce86c859e175530fa485711ff61615//apr-util-1.6.1/config.log
/home/rclinux/rc-buildroot-test/scripts/instance-1/output/host/arm-buildroot-linux-uclibcgnueabihf/sysroot/usr/include/features.h:218:5:
error: #warning requested reentrant code, but thread support was disabled [-Werror=cpp]
cc1: all warnings being treated as errors
Due to this warning 'ac_cv_ldap_set_rebind_proc_style' is set to two
instead of three leading to a build error later on. This patch forces
ac_cv_ldap_set_rebind_proc_style=three to be inline with openldap which
fixes
http://autobuild.buildroot.net/results/241/241ed78b93ce86c859e175530fa485711ff61615/
This solution was inspired by a discussion on the fink mailinglist:
https://sourceforge.net/p/fink/mailman/message/31720482/
Signed-off-by: Bernd Kuhls <bernd.kuhls@t-online.de> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Julien Boibessot [Thu, 10 May 2018 14:37:26 +0000 (16:37 +0200)]
package/qt5cinex: fix download
The Buildroot dl-wrapper tries to download
Qt5_CinematicExperience_%22rpi_%221.0.tgz, which fails, so this commit
fixes the archive name by removing useless double quotes.
Signed-off-by: Julien Boibessot <julien.boibessot@armadeus.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Anisse Astier [Fri, 11 May 2018 20:50:37 +0000 (22:50 +0200)]
go: security bump to version 1.10.2
This bump contains many bug fixes, as well as the following security
issue, patched in Go 1.10.1:
CVE-2018-7187: The "go get" implementation in Go 1.9.4, when the
-insecure command-line option is used, does not validate the import path
(get/vcs.go only checks for "://" anywhere in the string), which allows
remote attackers to execute arbitrary OS commands via a crafted web
site.
Signed-off-by: Anisse Astier <anisse@astier.eu> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Anisse Astier [Fri, 11 May 2018 20:50:34 +0000 (22:50 +0200)]
go: cleanup cross-compilation support
Now that we fixed cross-compilation in the go package, cleanup the build
to remove the workaround added in 60c5c96ae109dcea48e0997b5e6e6645ac9b86
"package/go: Build host tools with host CC". We only need a single pass
to build the go toolchain.
Signed-off-by: Anisse Astier <anisse@astier.eu> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Actually if GOHOSTOS == GOOS || GOHOSTARCH == GOARCH the go build system assume
it's not cross compiling and uses the same toolchain for both the host and the
target. This commit adds a patch to enable the explicit
GO_ASSUME_CROSSCOMPILING in go build system and updates to go package
accordingly.
Yann E. MORIN [Fri, 11 May 2018 15:50:58 +0000 (17:50 +0200)]
docs/manual: using a branch name as FOO_VERSION does not work
For various reasons, we've always suggested users to avoid using a
branch as version string for their packages, because it does not work
as a they would expect:
- it is not reproducible, because the branch may change between two
builds that are done at different times;
- it does not even follow the branch, as Buildroot anyway generates
a local tarball, which it will reuse on subsequent builds.
Furthermore, since we fetch and not pull, any existing local branch
is not updated.
Yet, until recently, using a branch name would just work (with the
above limitations): the git tree was cloned, the branch checked out,
and the tarball created.
But with the advent of the git caching, using a branch name does not
work anymore. Indeed, we now do a git-fetch, and that does not create
a local master branch. So we can't check out master, because it does
not exist locally. And for other branches, as noticed above, the local
branch does not get udpated to the remote one.
Furthermore, the local branches are only created by chance, again as a
side-effect of trying to fetch the "special refs".
So, we can't say that we reliably support the use of a branch name.
Update the manual to state that using a branch does not work. Remove
the 'stable' example, as it looked like the name of a stable branch;
instead, replace it with a version string that ressemble a tag.
Fix the layout of the manual by making the version examples an actual
bulleted list.
Note: the above is only entirely true for git. For Mercurial, CVS and
subversion, the status may be mixed, but nonetheless, using branches is
still a bad idea, if at least because it is not reproducible, and
because Buildroot does not even follow the branch. So, we do not
differentiate between the various SCMs, and just flatly state that using
a branch name is not supported.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Thomas De Schampheleire <patrickdepinguin@gmail.com> Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Cc: Maxime Hadjinlian <maxime.hadjinlian@gmail.com> Cc: Peter Korsgaard <peter@korsgaard.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Baruch Siach [Thu, 10 May 2018 15:42:12 +0000 (18:42 +0300)]
strace: disable (again) mpers for musl
It turns out that mpers support in strace still does not play nicely
with musl libc. As explained in commit 7892a778b (package/strace:
disable libmpers with musl toolchains) headers mixup causes gcc header
to be included, instead of the musl one, resulting in conflicting types.
Commit 1088372941 (strace: bump to version 4.21) incorrectly enabled
mpers for musl. Revert that.
Yann E. MORIN [Fri, 11 May 2018 16:29:57 +0000 (18:29 +0200)]
package/dahdi-linux: use package's DL_DIR
Since we reworked the download infra, the location for packages to look
for their files has moved to a per-package directory.
For systems where a download of the dahdi firmware files was already
done in a version prior to the rework, all was working fine so far,
because the files were indeed in the main DL directory.
But for systems where the download is first attempted after the rework,
the files are not found (even though they are properly downloaded).
Fix the location where dahdi-linux looks for its extra files.
Reported-by: ***** ***** <zyama.abel@mail.ru> Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: ***** ***** <zyama.abel@mail.ru> Cc: Carlos Santos <casantos@datacom.ind.br> Cc: Maxime Hadjinlian <maxime.hadjinlian@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Yann E. MORIN [Fri, 11 May 2018 16:29:56 +0000 (18:29 +0200)]
package/asterisk: use package's DL_DIR
Since we reworked the download infra, the location for packages to look
for their files has moved to a per-package directory.
For systems where a download of the asterisk sound files was already
done in a version prior to the rework, all was working fine so far,
because the files were indeed in the main DL directory.
But for systems where the download is first attempted after the rework,
the files are not found (even though they are properly downloaded).
Fix the location where asterisk looks for its extra files.
Reported-by: ***** ***** <zyama.abel@mail.ru> Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: ***** ***** <zyama.abel@mail.ru> Cc: Carlos Santos <casantos@datacom.ind.br> Cc: Maxime Hadjinlian <maxime.hadjinlian@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Yann E. MORIN [Wed, 9 May 2018 17:59:24 +0000 (19:59 +0200)]
support/dependencies: check that PATH does not contain CWD
A person on IRC reported a build failure with the util-linux package,
looking like this:
for I in uname26 linux32 linux64 ; do \
cd /home/aep/consulting/chargery/tracker/output/target/usr/bin && ln -sf setarch $I ; \
done
[...]
/bin/sh: line 1: ./ln: cannot execute binary file: Exec format error
/bin/sh: line 1: ./ln: cannot execute binary file: Exec format error
/bin/sh: line 1: ./ln: cannot execute binary file: Exec format error
The issue was an empty path in the PATH variable, which means "current
working directory", causing a "ln" binary built by util-linux for the
target to be used instead of the system-provided "ln".
We already check a number of things in the PATH and LD_LIBRARY_PATH
variables in support/dependencies/dependencies.sh, but we were not
checking that PATH did not contain an empty path.
This commit fixes that and takes this opportunity to simplify the test
code for PATH and LD_LIBRARY_PATH.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
[Thomas: improve commit log.] Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Bernd Kuhls [Tue, 1 May 2018 07:10:17 +0000 (09:10 +0200)]
package/mplayer: remove package
This package causes numerous build errors. During the last hackaton it
was decided to remove this package:
http://lists.busybox.net/pipermail/buildroot/2018-April/217514.html
Bernd Kuhls [Tue, 1 May 2018 07:10:16 +0000 (09:10 +0200)]
package/tovid: switch from mplayer to mpv
The mplayer package will be removed from buildroot, tovid can use mpv
instead. Support for mpv was added upstream:
https://github.com/tovid-suite/tovid/commit/05cbce2ea130e50f6bf1599816dd0d7bf3ace91a
Signed-off-by: Bernd Kuhls <bernd.kuhls@t-online.de> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Bernd Kuhls [Tue, 1 May 2018 07:10:15 +0000 (09:10 +0200)]
package/tovid: bump version
Support for mpv is not present in the tarball version 0.35.2, therefore
we bump this package to current git master branch to prepare the switch
from mplayer to mpv.
Added license hash.
Signed-off-by: Bernd Kuhls <bernd.kuhls@t-online.de> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Building the only package depending on libcrossguid, Kodi, breaks due to
this bump:
/home/buildroot/br4/output/build/kodi-17.6-Krypton/xbmc/utils/
StringUtils.cpp: In static member function ‘static std::__cxx11::string
StringUtils::CreateUUID()’:
/home/buildroot/br4/output/build/kodi-17.6-Krypton/xbmc/utils/
StringUtils.cpp:1194:10: error: ‘GuidGenerator’ does not name a type
static GuidGenerator guidGenerator;
^~~~~~~~~~~~~
/home/buildroot/br4/output/build/kodi-17.6-Krypton/xbmc/utils/
StringUtils.cpp:1195:15: error: ‘guidGenerator’ was not declared in this
scope
auto guid = guidGenerator.newGuid();
^~~~~~~~~~~~~
This happens due to changes in libcrossguid:
https://github.com/graeme-hill/crossguid/blob/master/README.md
"This is version 0.2 of CrossGuid. If you all already using CrossGuid and
your code uses GuidGenerator then you are using version 0.1."
Even Kodi master branch has no support for libcrossguid-0.2.x yet so we
revert the bump.
Signed-off-by: Bernd Kuhls <bernd.kuhls@t-online.de> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Since commit https://github.com/smuellerDD/libkcapi/commit/af313accf18887b4f6dbd7306c2389ddf271c9b7,
hasher test application depends on dlfcn.h. To avoid putting all apps
under !BR2_STATIC_LIBS dependency, split BR2_PACKAGE_LIBKCAPI_APPS into
several variables.
Moreover, BR2_USE_MMU is only a dependency of BR2_PACKAGE_LIBKCAPI_TEST
as other applications don't use fork.
Finally, enc or dgst applications could be enabled in a next patch if
needed.
Stefan Sørensen [Mon, 7 May 2018 12:28:43 +0000 (14:28 +0200)]
dropbear: Do not build static binary
Dropbear 2018.76 now uses the --enable-static option to indicate that a static
binary should be built. This will incorrectly pick up the generic buildroot
option intended for building static libraries, causing an unwanted static
binary build with BR2_SHARED_STATIC_LIBS.
Fix by appending an --disable-static configure flag, overriding the buildroot
default.
Signed-off-by: Stefan Sørensen <stefan.sorensen@spectralink.com> Reviewed-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Peter Korsgaard [Mon, 7 May 2018 18:35:01 +0000 (20:35 +0200)]
busybox: S01mdev: fix module autoloading
Commit b4fc5a180c (package/busybox: support spaces in module aliases in
mdev) changed the mdev coldplugging to handle sysfs path elements and
modalias values containing spaces. This unfortunately doesn't work as was
recently reported:
The problem is that sort -z also expects the fields of the input files to be
zero terminated, which is not the case for modalias sysfs entries.
So drop the -z option to sort. Spaces in modalias entries could be handled
with the xargs -d '\n' option, but that is unfortunately not supported by
the busybox applet. Instead, use tr to convert newlines to zeros so we can
use xargs -0.
Reported-by: Daniel Palmer <daniel@0x0f.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
mesa3d: fix build with gcc <= 4.7 on some architectures
The configure.ac check for atomic intrinsics assumes that if an atomic
intrinsic is not available, it's because we must link with
libatomic. Except that libatomic is not always available, for example
with gcc <= 4.7.
To fix this, this commit adds a patch that reworks the atomic check in
configure.ac. It has been submitted upstream, and tested in a number
of different combinations.
Peter Seiderer [Mon, 30 Apr 2018 19:47:17 +0000 (21:47 +0200)]
gst1-plugins-ugly: fix x264 compile failure
Add upstream patch to fix compile with latest x264 library.
Fixes [1]:
gstx264enc.c: In function 'plugin_init':
gstx264enc.c:2900:36: error: 'x264_bit_depth' undeclared (first use in this function); did you mean 'x264_picture_t'?
default_vtable.x264_bit_depth = &x264_bit_depth;
^~~~~~~~~~~~~~
x264_picture_t
The libfreeimage source code uses DOS line endings, which gets stripped by
patchwork so the patch no longer applies. Fix it by converting line endings
of the patch hunks to DOS (but not the patch meta data).
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Thomas Petazzoni [Sun, 22 Apr 2018 12:23:50 +0000 (14:23 +0200)]
binutils: replace hard-links with soft-links to fix rpath
binutils installs its binaries both as bin/<tuple>-<tool> and as
<tuple>/bin/<tool>, and hardlinks are used to reduce disk space
consumption. This causes a problem for host-binutils with our rpath
fixing logic done by "make sdk".
Indeed, the fix-rpath script starts by fixing up the rpath of
bin/<tuple>-<tool>, and sets the RPATH to $ORIGIN/../lib/. Then
fix-rpath moves on to <tuple>/bin/<tool>, and doesn't find the library
the tool depends on, and clears the RPATH. The result is that the
binutils tool are not usable.
Note that this is only visible currently on the ARC architecture,
because on this architecture, binutils is fetched from git, which
causes host-flex to be built, and some binutils tools to use the libfl
shared library. Therefore, the binutils tools don't use just the
standard C library (which is provided by the system) but also libfl
from $(HOST_DIR)/lib, and therefore if the RPATH isn't set correctly,
those tools don't work properly.
In order to address this, this comit adds a post-install hook to
host-binutils that replaces those hard links by symbolic links. It is
worth mentioning that library loading and RPATH usage occurs *after*
resolving the symbolic links, which makes this solution work.
Thomas Petazzoni [Sun, 22 Apr 2018 21:20:05 +0000 (23:20 +0200)]
udftools: fix static linking against readline
One program of udftools uses the readline library, but fails to build
in static linking configurations. In order to fix this, we teach
udftools configure.ac to use pkg-config to detect the readline
library, and to use the proper flags provided by pkg-config.
This obviously requires an autoreconf of the package, and the addition
of host-pkgconf in the dependencies.
Thomas Petazzoni [Sun, 22 Apr 2018 21:20:04 +0000 (23:20 +0200)]
readline: install a .pc file
Some packages (such as udftools) fail to build against readline in
static linking configurations. To fix this, we install the .pc file
provided by readline.
Unfortunately, this .pc file is by default not correct, so a patch is
added to fix it, and this patch requires to re-autoconf the package
(but not autoreconf since only autoconf is used).
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Thomas Petazzoni [Sun, 22 Apr 2018 21:20:03 +0000 (23:20 +0200)]
udftool: add missing dependency on readline
udftool/Config.in selects BR2_PACKAGE_READLINE, but udftool does not
depend on it. Readline is not a runtime dependency: one of the udftool
program links against it.
This commit fixes this inconsistency.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
LINUX_DTS_NAME may end up with a leading space because of the += logic, and
may contain multiple dts files - Neither of which works when we construct
the {cu,simple}Image.$(LINUX_DTS_NAME) make target name.
Fix it by using the first word in the variable.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Yann E. MORIN [Sun, 6 May 2018 11:57:51 +0000 (13:57 +0200)]
package/patch: fix xattr option
The name of the configure option is, and has always been,
--enable-xattr, not --enable-attr. Otherwise, configure
whines:
configure: WARNING: unrecognized options: --enable-attr
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Some files of log4cplus are licensed under BSD-2-Clause as stated in
LICENSE file: "Each file of log4cplus source is licensed using either
two clause BSD license or Apache license 2.0."
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Fabio Estevam [Sat, 5 May 2018 23:12:24 +0000 (20:12 -0300)]
configs/freescale_imx6ulevk: Remove target
Currently this target fails to build:
./scripts/dtc-version.sh: line 17: dtc: command not found
./scripts/dtc-version.sh: line 18: dtc: command not found
*** Your dtc is too old, please upgrade to dtc 1.4 or newer
Even though the fix for this build failure is easy, I prefer to
maintain only imx6ulevk_defconfig, which is a target for the
same board, but uses mainline kernel and U-Boot versions instead.
Fixes: https://gitlab.com/buildroot.org/buildroot/-/jobs/66561695 Signed-off-by: Fabio Estevam <festevam@gmail.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Fabio Estevam [Sat, 5 May 2018 23:12:23 +0000 (20:12 -0300)]
configs/freescale_imx31_3stack: Remove target
Currently this target fails to build:
arch/arm/mach-imx/built-in.o: In function `init_mmdc_lpddr2_settings':
platform-spi_imx.c:(.text+0x8f18): undefined reference to `imx6sll_lpddr2_freq_change'
arch/arm/mach-imx/built-in.o: In function `imx6ul_cpuidle_init':
platform-spi_imx.c:(.init.text+0x195c): undefined reference to `mx6ull_lpm_wfi_end'
platform-spi_imx.c:(.init.text+0x1960): undefined reference to `mx6ull_lpm_wfi_start'
platform-spi_imx.c:(.init.text+0x1964): undefined reference to `imx6ull_low_power_idle'
arch/arm/mach-imx/built-in.o: In function `imx6sl_init_late':
platform-spi_imx.c:(.init.text+0x56f0): undefined reference to `imx6sll_cpuidle_init'
Makefile:969: recipe for target 'vmlinux' failed
NXP 4.9 kernel does not properly support mx31, so better remove this target.
mx31_3stack board is currently supported in U-Boot and kernel mainline,
so if someone is interested on this board, then a target can be introduced
later which uses these mainline components.
Currently I do not have access to this board, so remove it its defconfig
for now.
Fixes: https://gitlab.com/buildroot.org/buildroot/-/jobs/66561688 Signed-off-by: Fabio Estevam <festevam@gmail.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Fabio Estevam [Sat, 5 May 2018 23:12:22 +0000 (20:12 -0300)]
configs/freescale_imx6sololiteevk: Remove target
Currently this target fails to build:
Error: No BOOT_FROM tag in board/freescale/mx6slevk/imximage.cfg.cfgtmp
arch/arm/imx-common/Makefile:91: recipe for target 'u-boot-dtb.imx' failed
This problem has been already solved in upstream U-Boot, but not
on NXP version of U-Boot.
To avoid the maintainance burden of keeping two defconfigs for the
same board, remove freescale_imx6sololiteevk_defconfig in favor
of imx6slevk_defconfig, which uses U-Boot and kernel mainline.
Fixes: https://gitlab.com/buildroot.org/buildroot/-/jobs/66561693 Signed-off-by: Fabio Estevam <festevam@gmail.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Carlos Santos [Sat, 5 May 2018 02:34:28 +0000 (23:34 -0300)]
nasm: Fix compilation with GCC 8
host-nasm fails to compile with GCC 8:
In file included from ./include/nasm.h:46,
from asm/nasm.c:47:
./include/nasmlib.h:194:1: error: ‘pure’ attribute on function returning ‘void’ [-Werror=attributes]
void pure_func seg_init(void);
^~~~
Pull a patch from upstream that removes the stale declaration of
seg_init, which was eliminated a long time ago.
Signed-off-by: Carlos Santos <casantos@datacom.ind.br> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Stefan Sørensen [Thu, 3 May 2018 11:46:59 +0000 (13:46 +0200)]
dropbear: Fix host key loading with 521 bit ecdsa keys
Dropbear 2018.76 changed the default ecdsa host key size form 521 to 256
bits, but this breaks systems with an existing 521 bit key, blocking ssh
logins.
Apply the upstream fix from https://secure.ucc.asn.au/hg/dropbear/rev/0dc3103a5900 :
Only advertise a single server ecdsa key when -R (generate as required) is
specified. Fixes -R now that default ecdsa key size has changed.
[Peter: apply-patches.sh does not like suffix-less filename, so include
patch in Buildroot] Signed-off-by: Stefan Sørensen <stefan.sorensen@spectralink.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
projects / coffee / buildroot.git / log