- Feb 26, 2017
-
-
Peter Korsgaard authored
Signed-off-by:Peter Korsgaard <peter@korsgaard.com>
-
Thomas Petazzoni authored
The libuv library uses __sync atomic built-ins: $ readelf -a -W output/target/usr/lib/libuv.so.1.0.0 | grep __sync 122: 00000000 0 NOTYPE GLOBAL DEFAULT UND __sync_val_compare_and_swap_4 but this is not currently taken into account in the libuv package, causing some build failures in packages using libuv as an optional dependency, such as janus-gateway and mosquitto. Therefore, this commit updates the libuv package with this additional dependency. The reverse dependencies of libuv are also updated: luv, luvi and moarvm. Fixes: - http://autobuild.buildroot.net/results/bdaa67d763c0d8d377a04529c74f73bee7d4ccef/ (janus-gateway) - http://autobuild.buildroot.net/results/2bc84ba2d1167018e2d48e5183ead22b6425dcf5/ (mosquitto) [Peter: drop cmake changes after cmake revert] Signed-off-by:
Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by:
-
Thomas Petazzoni authored
htop wants to use backtrace() support from the C library. Unfortunately, with old uClibc versions such as the one we use for the ARC architecture, the backtrace() implementation is in libubacktrace. In addition, this implementation needs dladdr() support, which is in libdl, not available when static linking. Since this problem no longer exists in more recent versions of uClibc, we simply special case the ARC+static linking case, and make the configure script believe that <execinfo.h> is not available. Fixes: http://autobuild.buildroot.net/results/cdea351fad7a0f61ddec3e6a141da8da0523a902/ Signed-off-by:
-
Thomas Petazzoni authored
The Buildroot manual documents that <pkg>_CONF_ENV is passed in the environment when calling cmake during the configure step. However, the actual implementation in pkg-cmake passes HOST_<pkg>_CONF_ENV when configuring the host variant of a cmake package, but does not pass <pkg>_CONF_ENV when configuring the target variant of a cmake package. This commit fixes that by passing <pkg>_CONF_ENV in the environment as expected. It should not cause any behavior change, because this feature is in fact not used by any package in upstream Buildroot: $ grep CONF_ENV $(git grep -l cmake-package package/) package/pkg-cmake.mk:$(2)_CONF_ENV ?= package/pkg-cmake.mk: $$($$(PKG)_CONF_ENV) $$(BR2_CMAKE) $$($$(PKG)_SRCDIR) \ package/pkg-cmake.mk: $$($$(PKG)_CONF_ENV) $$(BR2_CMAKE) $$($$(PKG)_SRCDIR) \ This issue was reported by Olivier <ovalentin@awox.com> as bug #9616. Signed-off-by:
"Yann E. MORIN" <yann.morin.1998@free.fr> Signed-off-by:
-
Yann E. MORIN authored
cmake 3.7 causes serious regressions in some cmake-based packages, related to how RPATH is handled. This reverts commit 1ffcf364. Signed-off-by:
-
Yann E. MORIN authored
cmake 3.7 causes serious regressions in some cmake-based packages, related to how RPATH is handled. This reverts commit d96fafc3. Signed-off-by:
-
Yann E. MORIN authored
cmake 3.7 causes serious regressions in some cmake-based packages, related to how RPATH is handled. This reverts commit b7542375. Signed-off-by:
-
Yann E. MORIN authored
cmake 3.7 causes serious regressions in some cmake-based packages, related to how RPATH is handled. This reverts commit f8a6990c. Signed-off-by:
-
Yann E. MORIN authored
DirectFB is written in C++, but can be linked to by a C library or program. When doing shared link, this is fine because the linker gets help from the DT_NEEDED flags and knows what libraries to pull in during the link. However, during a static link, the linker does not get such help. Properly fixing this would require that there is support in pkg-config and autotools to specify that the C++ runtime must be linked. Alas there is no sush support. The only option is to add -lstdc++ to the Libs.Private field in directfb.pc. But this is not upstreamable, because there are other C++ runtimes in the wild (e.g. -lc++ from llvm/clang). However, DirectFB in a static scenario is probably not a very common scenario. Disable DirectFB for static builds. Fixes: http://autobuild.buildroot.org/results/3d3/3d3036d40ddad71d872d910aae7a24975706d2e9/ http://autobuild.buildroot.org/results/d1c/d1c35a6003396942b584f2f2a5e8bf4ac2fbe370/ http://autobuild.buildroot.org/results/d45/d4504871bd47930e8363032d380cdfcc5bb8aee7/ [...] Signed-off-by: -
Angelo Compagnucci authored
* Remove distribution upgrade cause it slows down the first boot and presents a bug when executed non interactively. * Reorganize provision scripts to be in privileged and non privileged sections * Add Ubuntu mirror automatic handling for apt packages sources Fixes bug #9581 Signed-off-by:
Angelo Compagnucci <angelo.compagnucci@gmail.com> Signed-off-by:
-
Waldemar Brodkorb authored
Fixes: http://autobuild.buildroot.net/results/a0bb5535fd197b9dd1607a5f0bca477c9575c99f Signed-off-by:
Waldemar Brodkorb <wbx@openadk.org> Signed-off-by:
-
Thomas Petazzoni authored
The ncurses sub-options BR2_PACKAGE_NCURSES_TARGET_{FORM,MENU,PANEL} are currently very badly broken: they only control whether the libform, libmenu and libpanel libraries are installed in $(TARGET_DIR), but do absolutely nothing about their installation in $(STAGING_DIR). This means that when one of those options is disabled, the corresponding library is indeed not installed in the target, but is available in staging. It can therefore be detected by the configure script of another package and used... even though the library will not be in the target, causing a runtime failure. Internally, ncurses.mk uses the "make install" logic of ncurses for the staging installation, but uses a completely hand-written logic for the target installation, which is the reason for this desynchronization between what's installed in staging and target. When BR2_PACKAGE_NCURSES_WCHAR=y, this also causes some build failures. Indeed, when BR2_PACKAGE_NCURSES_WCHAR=y, Buildroot creates some symbolic links lib<foo>.so -> lib<foo>w.so in staging and target, but only for the lib<foo> that have been enabled by BR2_PACKAGE_NCURSES_TARGET_{FORM,MENU,PANEL}. Due to this, a package that for example needed the libmenu library but forgot to select BR2_PACKAGE_NCURSES_TARGET_MENU was: - Building fine with BR2_PACKAGE_NCURSES_WCHAR disabled (because libmenu.so exists in staging), but would fail to run at runtime because libmenu.so is not in the target. - Fail to build with BR2_PACKAGE_NCURSES_WCHAR=y because only libmenuw.so exists, and not the libmenu.so symbolic link. Since those libraries are small (43K for libform, 21K for libmenu and 8.2K for libpanel), this commit takes the very simple approach of removing those options, and installing the libraries unconditionally. It therefore uses the "make install" logic for both the staging *and* target installation. In detail, this commit: - Removes the NCURSES_PROGS variable, not needed since --without-progs already allows to disable the build and installation of programs. - Removes the NCURSES_LIBS-y variable, and replaces it with a single unconditional assignement to NCURSES_LIBS, only used to create the lib<foo>w.so -> lib<foo>.so symbolic links when wchar support is enabled. - Removes NCURSES_INSTALL_TARGET_CMDS and the functions it was calling: NCURSES_INSTALL_TARGET_LIBS and NCURSES_INSTALL_TARGET_PROGS. - Adds a NCURSES_TARGET_SYMLINK_RESET hook to create the reset -> tset symbolic link, as was done before. - Adds a NCURSES_TARGET_CLEANUP_TERMINFO to cleanup the terminfo files in the target, so that we stay in the same situation in terms of installed terminfo files. - Removes the BR2_PACKAGE_NCURSES_TARGET_{FORM,MENU,PANEL} options from the Config.in files: both their definition and usage. - Simplifies all the symlink dance for lib<foo> -> lib<foo>w, because as Yann E. Morin suggested, this dance is only needed in staging, not in the target. Once binaries have been built, they refer to the SONAME of the library, which is the lib<foo>w variant (for shared linking). For static linking and .pc files, it's obvious that we don't care about them on the target. Therefore the NCURSES_LINK_LIBS_STATIC, NCURSES_LINK_LIBS_SHARED and NCURSES_LINK_PC functions no longer take any argument: they always apply to STAGING_DIR only. NCURSES_LINK_TARGET_LIBS is removed. It is worth mentioning that adding Config.in.legacy support is *NOT* necessary. Indeed: - If they were disabled before this patch, having them in Config.in.legacy would not trigger the legacy warning. - If they were enabled before this patch, then the behavior is unchanged: all libraries are now unconditionally installed. So there is no point in warning the user. We double-checked the installed size of a filesystem containing just ncurses before and after this patch, and the only folder that has its size changed is /usr/lib, growing from 852 KB to 932 KB in the wchar enabled case. That's a 80 KB system size increase. This commit fixes the sngrep build failure and potentially numerous runtime issues with ncurses. Fixes: http://autobuild.buildroot.net/results/7b5db21a6c568e6c6c8fe2b5d5a2f5ca24df510c/ Signed-off-by: -
Fabio Estevam authored
Signed-off-by:
Fabio Estevam <festevam@gmail.com> Signed-off-by:
-
Fabio Estevam authored
Signed-off-by:
-
Ignacy Gawędzki authored
Since there's not much point in generating missing host keys when the init script is called with "stop", the call to ssh-keygen should not be done inconditionally, but in the start function instead. Signed-off-by:
Ignacy Gawędzki <ignacy.gawedzki@green-communications.fr> Acked-by:
-
Fabio Estevam authored
Signed-off-by:
-
Fabio Estevam authored
Signed-off-by:
-
Yann E. MORIN authored
xfsprogs links to some libraries from util-linux. Those in turn may use i18n functions when locales are enabled. When doing a uClibc build, those i18n functions are provided by the libintl library from the gettext package. xfsprogs does not use pkgconfig to find the util-linux libraries, so it misses the Requires.private field from libblkid, and thus misses the Libs.private field from libuid. And so a static link fails because of undefined references to i18n symbols. Furthermore, xfsprogs does not use automake; the hand-made Makefiles do not make use of the LIBS variable set by configure. We fix that in two ways: - pass LIBS=-lintl to configure, so that the configure step has a chance to succeed (as suggested by Waldemar) - patch a Makefile to link with EXTRALIBS, and pass EXTRALIBS via XFSPROGS_MAKE_OPTS Fixes: http://autobuild.buildroot.org/results/503/50314716a9f72e8bb238e52e9dc342c68f7e0b8b/ http://autobuild.buildroot.org/results/253/253a024698b55dece992b2631e30edf4ff9092f7/ http://autobuild.buildroot.org/results/3fe/3fe0d96cf13af12b0051a95f7865d4e38f4a78af/ http://autobuild.buildroot.org/results/d48/d48e61785d25d33106b7dab1b5cb200cf27d4044/ ... Signed-off-by: -
Waldemar Brodkorb authored
Fixes nmap build for sparc. Fixes: http://autobuild.buildroot.net/results/8e476939f1daaa20c316dbd0508fa343034f2397 Signed-off-by:
-
Peter Korsgaard authored
Fixes: http://autobuild.buildroot.net/results/05b/05bbc22dd6cd5564462226e612ab1e95778fe935/ http://autobuild.buildroot.net/results/edf/edfe58749d1b7a1bb2e0184a6824a74b9d38ddb9/ http://autobuild.buildroot.net/results/139/1395eca13ca537bde928ddd68a5bc6e130e82ba3/ http://autobuild.buildroot.net/results/94a/94ad6e8bbbeb926ea834d9d6e3ba87d0398acb86/ Gcc 6.x defaults to C++14, and the iostream operator bool behaviour changed in C++11. In previous versions, a somewhat odd operator void* was used to return the status of the stream as a pointer. Since C++11 a more sensible operator bool is used to return the stream staus. For details, see: http://en.cppreference.com/w/cpp/io/basic_ios/operator_bool The code in CConfigReadContext assumes the pre-C++11 behaviour and provides its own operator void overload to return the status of the embedded iostream. With C++11, iostream no longer provides this overload, breaking the build: CConfig.cpp: In member function 'CConfigReadContext::operator void*() const': CConfig.cpp:1851:9: error: cannot convert 'std::istream {aka std::basic_istream<char>}' to 'void*' in return return m_stream; To fix it, backport part of upstream commit 3d963bfbe7897d0a33ad (possible fix for mavericks) which changes the code to simply provide a getStream() method which returns a reference to the embedded stream and the calling code is changed to use operator bool on the returned stream, making the code compatible with both old and new compilers. This upstream commit is part of the 1.6.0 release, so can be dropped when the version is bumped. Signed-off-by:
-
- Feb 25, 2017
-
-
Waldemar Brodkorb authored
The workarounds for kmod/libnss can be removed when the patch is applied and the autobuilder toolchains got rebuild. kmod: 0d81107f libnss: fceb1afd Signed-off-by:
-
Yann E. MORIN authored
The path is a remnant from before the rename of the package. Rather than hard-code the path, use the available variable. Also use that variable when copying the Sys-V init script. Fixes: http://autobuild.buildroot.org/results/767/767f0be3894c45c1e6d18bc4528d0da7b50e3757/ http://autobuild.buildroot.org/results/e93/e934683ebcb33c9cc8fe9de7b1d5dcd7866f3bce/ http://autobuild.buildroot.org/results/5d0/5d04163de80f7900d4aed14cff75b2e0761f101d/ Signed-off-by:
-
- Feb 24, 2017
-
-
Jesper Baekdahl authored
libanl.so is needed for asynchronous network address and service translation, declared in netdb.h Signed-off-by:
Jesper Bækdahl <jbb@gamblify.com> Signed-off-by:
-
Jesper Baekdahl authored
libanl.so is needed for asynchronous network address and service translation, declared in netdb.h Signed-off-by:
-
Thomas Petazzoni authored
Commit a5015f10 ("util-linux: security bump to version 2.29.2") incorrectly removed <pkg>_AUTORECONF = YES. While the patches touching configure.ac have indeed been removed, there is still a patch touching a Makemodule.am file, which triggers an autoreconf a build time, which itself fails because autoconf/automake are not available. So re-add <pkg>_AUTORECONF, with a comment pointing specifically at the patch that makes it necessary. Fixes: http://autobuild.buildroot.net/results/309127a532eed00e406bbaf0b1a51b7241a10505/ Signed-off-by:
-
Luca Ceresoli authored
Signed-off-by:
Luca Ceresoli <luca@lucaceresoli.net> Signed-off-by:
-
Yann E. MORIN authored
configure.ac uses PKG_CHECK_MODULES() so it needs host-pkgconf. Signed-off-by:
-
- Feb 23, 2017
-
-
Chris Smart authored
Currently the host build of Python 2 defaults to narrow unicode (UCS2), ignoring the BR2_PACKAGE_PYTHON_UCS4 configuration option which may be set to wide (UCS4). This results in host and target Python packages which are incompatible in subtle ways. For example, installing wheels into the target fails when they are made with the host python, citing incompatibility (as can be seen by the package tags which may be "cp27u-manylinux1" instead of "cp27mu-manylinux1"). Compiling the host Python 2 with the same UCS configuration as the target ensures that the packages are compatible (and the tags match). This does not affect Python 3 as support for narrow unicode was deprecated in version 3.3, see https://www.python.org/dev/peps/pep-0393/ Thanks to Tony Breeds <tony@bakeyournoodle.com> for reporting this. Signed-off-by:
Chris Smart <mail@csmart.io> [Thomas: add comment in the code.] Signed-off-by:
-
Gustavo Zacarias authored
Signed-off-by:
Gustavo Zacarias <gustavo@zacarias.com.ar> Signed-off-by:
-
Gustavo Zacarias authored
Signed-off-by:
-
Gustavo Zacarias authored
Signed-off-by:
-
Gustavo Zacarias authored
It updates to the ffmpeg 3.2.4 codebase, fixing several security bugs. Signed-off-by:
-
Gustavo Zacarias authored
Fixes: CVE-2017-5847 - The gst_asf_demux_process_ext_content_desc function in gst/asfdemux/gstasfdemux.c in gst-plugins-ugly in GStreamer allows remote attackers to cause a denial of service (out-of-bounds heap read) via vectors involving extended content descriptors. Signed-off-by:
-
Gustavo Zacarias authored
Fixes: CVE-2017-5848 - The gst_ps_demux_parse_psm function in gst/mpegdemux/gstmpegdemux.c in gst-plugins-bad in GStreamer allows remote attackers to cause a denial of service (invalid memory read and crash) via vectors involving PSM parsing. Signed-off-by:
-
Gustavo Zacarias authored
Signed-off-by:
-
Gustavo Zacarias authored
Signed-off-by:
-
Gustavo Zacarias authored
Signed-off-by:
-
Yann E. MORIN authored
It turned out that the troll character U+c2a0 was added by our own patch. So fix it amd drop our second patch. Signed-off-by:
-
Thomas Petazzoni authored
This commit adds a patch to btrfs-progs that fixes the build of docker-engine, and possibly other packages including kerncompat.h from btrfs-progs. For the btrfs-progs build itself, a --disable-backtrace option allows to indicate whether backtrace()/<execinfo.h> support should be used or not. However, once btrfs-progs is installed, it simply looks at whether __GLIBC__ is defined or not to decide to use backtrace() or not. However, uClibc defines __GLIBC__ but does not provide backtrace() functionality. The additional patch tweaks the kerncompat.h to look at __UCLIBC__ and not use backtrace() functionality in this case. Fixes: http://autobuild.buildroot.net/results/9dc9370a79c5c44e6c92be6a44334842c211d923/ Signed-off-by:
-
Peter Seiderer authored
Fixes: Makefile:532: *** mbedtls is in the dependency chain of bctoolbox that has added it to its _DEPENDENCIES variable without selecting it or depending on it from Config.in. Stop. Signed-off-by:
Peter Seiderer <ps.report@gmx.net> Acked-by:
Jörg Krause <joerg.krause@embedded.rocks> Signed-off-by:
-
