The option is a non-option now and will be removed.
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Remove BR2_INET_IPV6 select for predefined external toolchains.
Remove the (non)IPv6 option prompt since it's now mandatory.
And force the toolchain check now that internal uclibc is always built
with IPv6 support and external non-IPv6 toolchains are disallowed.
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Remove the option to disable IPv6 support in uclibc and associated
logic.
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Normally we'd deprecate them, but:
1) They don't support IPv6 and it's being removed so it makes no sense.
2) They're based on uClibc 0.9.30-ish which is very old and surely has
package build breakage all over it.
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
For a multi-arch toolchain, gconv modules are in a sub-directory named
after the machine gcc targets. This is the case, for example, for the
Linaro ARM 2014.09 toolchain, which has the gconv modules in (relative
to the sysroot):
/usr/lib/arm-linux-gnueabihf/gconv
while the Sourcery CodeBench ARM 2014.05 (non-multi-arch) has them in:
/usr/lib/gconv
So, to catter for both cases, search both paths. We want to favour the
machine-specific gconv modules over potentially existing "generic" ones,
so we first search that (if it exists) and fallback to looking in the
generic location.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* Move service files to /usr/lib/systemd/system/
* Only disable systemd support on non-systemd systems
[Thomas: use positive logic for the systemd test.]
Signed-off-by: Mike Williams <mike@mikebwilliams.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The current configuration system does not check for cached variables for
these flags, and thus they are always disabled when cross-compiling.
This patch fixes the configuration system to use cached variables and
enables them at configuration time.
Signed-off-by: Lionel Orry <lionel.orry@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
This commit removes BR2_LINUX_KERNEL_EXT_RTAI_PATCH because this
option never worked. It was added in commit
8797a9cd1f, which added package/rtai/
and RTAI as a Linux extension.
The option prompt says "Path for RTAI patch file", so let's say you
specify /home/foo/bar/myrtai.patch as the value for
BR2_LINUX_KERNEL_EXT_RTAI_PATCH.
Then the code does:
RTAI_PATCH = $(call qstrip,$(BR2_LINUX_KERNEL_EXT_RTAI_PATCH))
and we have a package called 'rtai', so the normal logic of
<pkg>_PATCH applies. Since the <pkg>_PATCH value does not contain
ftp://, http:// or https://, the package infrastructure will try to
download $(RTAI_SITE)/$(RTAI_PATCH), i.e:
https://www.rtai.org/userfiles/downloads/RTAI/home/foo/bar/myrtai.patch
Pretty clear that it has no chance of working.
Now, let's assume an URL is used as the value of
BR2_LINUX_KERNEL_EXT_RTAI_PATCH, such as
http://foo.com/bar/myrtai.patch. In this case, it will be properly
downloaded by the package infrastructure. But then, the following code
kicks in:
define RTAI_PREPARE_KERNEL
$(APPLY_PATCHES) \
$(LINUX_DIR) \
$(dir $(RTAI_PATCH)) \
$(notdir $(RTAI_PATCH))
endef
The value of $(dir $(RTAI_PATCH)) will be http://foo.com/bar/. How
can $(APPLY_PATCHES) make use of such a stupid patch location?
[Thomas: add Config.in.legacy handling, as suggested by Arnout, even
if we believe that no-one could have ever used this option.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Add rngd.service for systemd. Also patch rngd with patch from Fedora to
ignore failure if no hwrng present:
https://bugzilla.redhat.com/show_bug.cgi?id=892178
[Thomas:
- rename patch to the proper naming convention
- add description and SoB to patch
- install service file to /usr/lib/systemd and not /lib/systemd
- use a relative symbolic link instead of an absolute one]
Signed-off-by: Maxim Mikityanskiy <maxtram95@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
When using busybox compiled from current git, login emits the following
message:
login: /etc/group: bad record
Fix it by adding the missing colon to /etc/group in system/skeleton.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Following problems found by buildroot should be fixed:
* static python2 compile (there is still a general problem, not related to uClibc-ng)
* postgresql configure hickup (link warnings got removed)
* samba runtime problems (RPATH in executables are respected)
Signed-off-by: Waldemar Brodkorb <wbx@openadk.org>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The manual target installation commands optionally copy 3 executables
that demonstrate the library usage, but do not the library itself.
This results in the following errors at runtime:
# openRTSP
openRTSP: can't load library 'libliveMedia.so.38'
# live555MediaServer
live555MediaServer: can't load library 'libliveMedia.so.38'
# MPEG2TransportStreamIndexer
MPEG2TransportStreamIndexer: can't load library 'libliveMedia.so.38'
#
Tested with the following defconfig, which is basically
qemu_arm_versatile_defconfig plus C++ and live555:
BR2_arm=y
BR2_KERNEL_HEADERS_VERSION=y
BR2_DEFAULT_KERNEL_VERSION="4.0"
BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_4_0=y
BR2_TOOLCHAIN_BUILDROOT_CXX=y
BR2_TARGET_GENERIC_GETTY_PORT="ttyAMA0"
BR2_LINUX_KERNEL=y
BR2_LINUX_KERNEL_CUSTOM_VERSION=y
BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="4.0"
BR2_LINUX_KERNEL_USE_CUSTOM_CONFIG=y
BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE="board/qemu/arm-versatile/linux-4.0.config"
BR2_LINUX_KERNEL_ZIMAGE=y
BR2_PACKAGE_LIVE555=y
BR2_TARGET_ROOTFS_EXT2=y
Fix the whole installation step by using the 'make install' step provided
by the upstream package, similar to what was done in commit
44d15563c7 for the staging installation.
Note: this change has the effect of installing unconditionally all the
test and demo executables produced by the live555 compilation process,
and that were previously not (or optionally) copied. This increases the
uncompressed target filesystem size by roughly 300 kB (tested for a
32-bit ARM target). Undesired files can be deleted in a post-build script.
Signed-off-by: Luca Ceresoli <luca@lucaceresoli.net>
Cc: Baruch Siach <baruch@tkos.co.il>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
As reported by Romain Naour, having a hash file for a package
downloaded from github is wrong.
Reported-by: Romain Naour <romain.naour@openwide.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Explanation from https://download.samba.org/pub/samba/README.FTP
Due to bandwidth usage, ftp downloads of Samba from samba.org are no
longer allowed. Please use one of our many mirror sites at
http://www.samba.org/ or to directly access the old site via http
please use http://download.samba.org/samba/ftp/
Signed-off-by: Sébastien Szymanski <sebastien.szymanski@armadeus.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Package now uses GNU autoconf infrastructure.
Signed-off-by: Bernd Kuhls <bernd.kuhls@t-online.de>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Package now uses GNU autoconf infrastructure.
Signed-off-by: Bernd Kuhls <bernd.kuhls@t-online.de>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
