We do not usually provide help for our internal scripts. Besides, such
help has a tendency to bitrot pretty quickly anyway.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Vadim Kochan <vadim4j@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Commit b14b02698 (core/br2-external: restore compatibility with old
distros) switched to using 'eval' to emulate associative arrays, for
those distros too old to have bash-4+.
In so doing, it forgot to declare the new local variables in the
respective helper functions.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Vadim Kochan <vadim4j@gmail.com>
Cc: Arnout Vandecappelle <arnout@mind.be>
Cc: Ricardo Martincoski <ricardo.martincoski@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
xz help indicates only 1 thread is used unless we set threads:
-T, --threads=NUM use at most NUM threads; the default is 1; set to 0
to use as many threads as there are processor cores
Since this splits the file into blocks, the result will be not
bit-for-bit identical to single-threaded compression. Therefore, don't
enable this in BR2_REPRODUCIBLE builds.
Signed-off-by: James Hilliard <james.hilliard1@gmail.com>
Reviewed-by: Matthew Weber <matthew.weber@rockwellcollins.com>
[Arnout: append the option instead of repeating the entire command]
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
U-Boot supports a number of environment variables to pass specific
information. The following patches were submitted in the past to one
some specific Config.in option to pass some of these variables:
- http://patchwork.ozlabs.org/patch/881197/ proposed an option to
pass a custom EXT_DTB= variable
- http://patchwork.ozlabs.org/patch/1018245/ proposed an option to
pass a custom DEVICE_TREE= variable
Instead of adding one Config.in option for each of those variables,
let's provide a generic mechanism to pass arbitrary variables during
U-Boot build step.
Cc: Konstantin Porotchkin <kostap@marvell.com>
Cc: Clemens Gruber <clemens.gruber@pqgruber.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Some packages test for CMAKE_SYSTEM explicitly[1]
CMAKE_SYSTEM is comprised of CMAKE_SYSTEM_NAME and CMAKE_SYSTEM_VERSION.
It defaults to CMAKE_SYSTEM_NAME if CMAKE_SYSTEM_VERSION is not set[2]
At the point CMAKE_SYSTEM_NAME is set to "Linux" CMAKE_SYSTEM is already
constructed. Setting it explicitly ensures that it is the correct value.
This is because we do set CMAKE_SYSTEM_NAME twice, in fact:
- first in toolchainfile.cmake, so that we tell cmake to use the
"Buildroot" platform,
- second, in the Buildroot.cmake platform definition itself, so that
we eventually behave like the Linux platform.
We also set CMAKE_SYSTEM_VERSION to 1, and so the real CMAKE_SYSTEM
value should be set to Linux-1 if we were to follow the documentation to
the letter.
However, for Linux, the version does not matter, and in some situations
may even be harmful (that was reported in one of the commits that
introduce Buildroot.cmake and toolchainfile.cmake).
[1] Fluidsynth 0cd44d00e1/CMakeLists.txt (L80)
[2] https://cmake.org/cmake/help/git-master/variable/CMAKE_SYSTEM.html#variable:CMAKE_SYSTEM
Signed-off-by: Frank Vanbever <frank.vanbever@mind.be>
Acked-by: Yann E. MORIN <yann.morin.1998@free.fr>
[Peter: update commit message with description from Yann]
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Bitcoin Core is an open source project which maintains and releases
Bitcoin client software called “Bitcoin Core”.
Signed-off-by: Fabio Urquiza <fabiorush@gmail.com>
[Thomas:
- Don't create a new blockchain applications sub-menu for now, put
this package in "Miscellaneous applications"
- Do not select BR2_INSTALL_LIBSTDCPP, use depends on instead, and
add the corresponding comment.
- Do not select BR2_TOOLCHAIN_BUILDROOT_USE_SSP. Instead pass
--disable-hardening, and let Buildroot pass the appropriate CFLAGS
when hardening features are enabled system-wide.
- Add missing BR2_TOOLCHAIN_HAS_ATOMIC dependency
- Add quirky !(BR2_arm || BR2_armeb) || BR2_USE_MMU because the
Cortex-M toolchains don't provide 8-byte __atomic intrinsics, but
we don't have a good way to express that today
- Add missing BR2_TOOLCHAIN_HAS_GCC_BUG_64735 due to the use of
std::future
- Use only one BITCOIN_CONF_OPTS assignment to pass all options]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Add a simple init script that invokes sysctl early in the initialization
process to configure kernel parameters. This is already performed by
systemd (systemd-sysctl) but there is no sysvinit/busybox counterpart.
Files are read from directories in the following list in the given order
from top to bottom:
/run/sysctl.d/*.conf
/etc/sysctl.d/*.conf
/usr/local/lib/sysctl.d/*.conf
/usr/lib/sysctl.d/*.conf
/lib/sysctl.d/*.conf
/etc/sysctl.conf
Signed-off-by: Carlos Santos <unixmania@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Add a simple init script that invokes sysctl early in the initialization
process to configure kernel parameters. This is already performed by
systemd (systemd-sysctl) but there is no sysvinit/busybox counterpart.
Files are read from directories in the following list in the given order
from top to bottom:
/run/sysctl.d/*.conf
/etc/sysctl.d/*.conf
/usr/local/lib/sysctl.d/*.conf
/usr/lib/sysctl.d/*.conf
/lib/sysctl.d/*.conf
/etc/sysctl.conf
A file may be used more than once, since there can be multiple symlinks
to it. No attempt is made to prevent this.
Signed-off-by: Carlos Santos <unixmania@gmail.com>
Reviewed-by: Matthew Weber <matthew.weber@rockwellcollins.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Some platform may generate specific boot image files instead of
the generic files tee.bin and tee-*_v2.bin when building OP-TEE OS
package.
This change introduces optee-os configuration directive
BR2_TARGET_OPTEE_OS_CORE_IMAGES that allows board configuration
to specify its expected boot image file names.
Signed-off-by: Etienne Carriere <etienne.carriere@linaro.org>
[Thomas: use the current hardcoded values as the default for the new
config option, to avoid breaking existing setups, and therefore use
$(wildcard ...) to support wildcards]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
The domain search option is from RFC3397, not RFC3359 (which is about TLV
codepoints), so fix that.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
This is useful in networks with internal resources as it allows
to use much shorter names.
E.g. instead of "server.internal.company.com" it's possible
to use just "server" if DHCP server is configured with:
---------------------------->8-----------------------
option domain-search "internal.company.com";
---------------------------->8-----------------------
This improvement consists of 2 parts:
1. Enable handling of RFC3397 so DHCP client is ready for processing
corresponding data from DHCP server.
2. Some DHCP servers always send out search list if it is set in server's
configuration and some servers only provide search list if client
asks for that (sending list of options it expects to get).
And exactly for those stubborn DHCP servers we need to add "-O search"
to udhcp's command line via CONFIG_IFUPDOWN_UDHCPC_CMD_OPTIONS.
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Cc: Ignacy Gawedzki <ignacy.gawedzki@green-communications.fr>
Cc: Peter Korsgaard <peter@korsgaard.com>
Acked-by: Yann E. MORIN <yann.morin.1998@free.fr>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
This patch introduces a recently released significant update to ARC HS
family: ARC HS48.
One of the major ARC HS48 features is dual-issue pipeline which requires a
little bit modified instruction scheduling compared to single-issue cores
(HS38), thus new "-mcpu/--with-cpu=hs4x".
Also to address some peculiarities of early designs based on HS48 we
introduced yet another "-mcpu/--with-cpu=hs4x_rel31" which we're going to use
as well on some of our development boards.
Signed-off-by: Evgeniy Didin <didin@synopsys.com>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Cc: arc-buildroot@synopsys.com
[Peter: fixup check-package warnings]
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Check external.mk is ignored only when in the root path of a
br2-external.
Add a file called external.mk as a fixture to be used by the test case.
Signed-off-by: Ricardo Martincoski <ricardo.martincoski@gmail.com>
Cc: Arnout Vandecappelle <arnout@mind.be>
[Arnout: wrap at 80 columns]
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
The external.mk file in a br2-external usually contains raw makefile
targets. This file is common code and not a package recipe so it should
not be tested against the code-style of a package .mk file.
When using this script to check files in a br2-external tree, usually
the user is responsible for not passing files that check-package do not
understand. But external.mk is special because it is part of the
br2-external structure, so it is likely someone expects it to be
checkable by an in-tree script.
Instead of adding another blob to the manual, just ignore this file.
Only do that when a br2-external is being tested (so with option -b
passed to the script) and also check that it is on the root path of the
br2-external to allow someone to have a package called external.
Reported on bug #11271.
Reported-by: Vitaliy Lotorev <lotorev@gmail.com>
Signed-off-by: Ricardo Martincoski <ricardo.martincoski@gmail.com>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
[Arnout: wrap at 80 columns]
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Check the basic usage for check-package.
It can be called using either absolute path, relative path or from PATH.
Files to be checked can be passed with either absolute path or relative
path (also including files in the current directory).
Also check it ignores some special files when checking intree files,
i.e. package/pkg-generic.mk, while still generating warnings for out-of-tree
files when called with -b.
In order to allow the later, add an empty line to the Config.in in the
br2-external being tested so the script does generate a warning.
Catches bug #11271.
More tests can be added later, for example compatibility to Python 3.
Suggested-by: Arnout Vandecappelle <arnout@mind.be>
Signed-off-by: Ricardo Martincoski <ricardo.martincoski@gmail.com>
Cc: Arnout Vandecappelle <arnout@mind.be>
[Arnout: wrap at 80 columns where appropriate; merge into a single
class.]
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Currently run-tests must be called from the Buildroot top directory.
Derive the top directory from the script path, so run-tests can be called from
any path.
As a consequence the test infra will always test the repo it belongs to.
Suggested-by: Yann E. MORIN <yann.morin.1998@free.fr>
Signed-off-by: Ricardo Martincoski <ricardo.martincoski@gmail.com>
Cc: Arnout Vandecappelle <arnout@mind.be>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Cc: Yann E. MORIN <yann.morin.1998@free.fr>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
One of the possible usages of check-package is to first cd to the
directory that contains the files to test (e.g. a package directory) and
then call the script passing the files in the current dir.
It already works when used for intree files, but for files in a
br2-external it throws an exception because some check functions (from
utils/checkpackagelib/lib_*.py) do need the name of the file being
processed and assume there will be a slash before the name.
Fix all check functions that assume that the full filename being checked
contains a slash. Do not use regexps to extract the filename, use
os.path functions instead.
Notice RemoveDefaultPackageSourceVariable and TypoInPackageVariable lead
to an exception in this case, but ApplyOrder instead generates a false
warning.
Fixes bug #11271.
Reported-by: Vitaliy Lotorev <lotorev@gmail.com>
Signed-off-by: Ricardo Martincoski <ricardo.martincoski@gmail.com>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Cc: Vitaliy Lotorev <lotorev@gmail.com>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
This patch adds a new jack1 package alongside the existing jack2.
While jack1 and jack2 are two equivalent implementations of the same
protocol, they differ in a few details and both of them are being
actively used (jack2 is not considered to be a replacement of jack1).
It is not possible to enable both at the same time, so hide away jack1
when jack2 is enabled (to keep existing defconfig files working).
For more information, see:
https://github.com/jackaudio/jackaudio.github.com/wiki/Q_difference_jack1_jack2
Signed-off-by: Adam Heinrich <adam@adamh.cz>
[yann.morin.1998@free.fr:
- fix coding style
- use the release tarball, not a git clone
]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
[Peter: add host-pkgconf dependency, reorder dependencies]
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The custom external toolchain logic asks the user to specify which gcc
version is provided by the toolchain. The list of gcc versions given
by Buildroot is restricted depending on the selected CPU architecture
using the BR2_ARCH_NEEDS_GCC_AT_LEAST_xyz config options.
However, these config options generally indicate in which upstream gcc
version the support for the selected architecture was introduced. But
in practice, it is possible that an external toolchain uses some
non-upstream gcc code, providing support for a CPU architecture before
it was merged in upstream gcc.
A specific example is that there are pre-built external toolchains for
the C-SKY CPU architecture that are based on gcc 6.x, even if the
support for it was only added in upstream gcc 9.x.
Due to the BR2_ARCH_NEEDS_GCC_AT_LEAST_xyz options, only gcc >= 9.x
can be selected for C-SKY, preventing the use of such a custom
toolchain.
In addition, those dependencies are in fact not really needed:
Buildroot will check that the gcc version provided matches what the
user declared in the configuration. And if the gcc provided by the
toolchain does support that CPU architecture, then well, so be it,
there's no need to restrict the gcc version selected.
So we simply get rid of these dependencies on
BR2_ARCH_NEEDS_GCC_AT_LEAST_xyz, and also don't use them anymore to
chose a default value for the gcc version.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Cc: Yann E. MORIN <yann.morin.1998@free.fr>
Acked-by: Yann E. MORIN <yann.morin.1998@free.fr>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
On Qt5 Latest package qt5webengine libnss that is affected by gcc bug
85862. However, that bug has now been worked around in libnss, so we
can remove the 'depends on !BR2_TOOLCHAIN_HAS_GCC_BUG_85862', as
libnss is now available even if the toolchain is affected by gcc bug
85862.
Signed-off-by: Giulio Benetti <giulio.benetti@micronovasrl.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
The recent addition of a RISC-V musl toolchain uncovered an issue in
Boost's endianness detection. Boost endianness detection only works
for C libraries that pretend to be glibc *or* if the architecture is
explicitly handled by Boost endian.h header. Neither were true for
RISC-V musl, so we slightly patch boost to fix this problem.
Fixes:
http://autobuild.buildroot.net/results/a40b600a7d0fdb6a8a1ded7883b4936f120811f5/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
The 0004-workaround-musl-bug.patch was added because musl's <sched.h>
was using memset(), but without including <string.h>. So including
just <sched.h> was causing a build failure.
However, this issue in musl has been fixed in upstream musl commit
48be5b6313d7b827acf555769e93b389fa9f6307 ("fix use of memset without
declaration in sched.h cpu set macros"). This commit was part of musl
1.1.17, which has been released a while ago. Both 2019.02.x, 2019.05.x
and master use a newer musl version.
So the workaround in Boost can be dropped.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
An ASCII-art game like Space Invaders using ncurses.
Signed-off-by: Thomas Huth <huth@tuxfamily.org>
Reviewed-by: Gilles Talis <gilles.talis@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Use the new builtin armv5 4.19 kernel to test atop.
The atop package cannot be tested using BASIC_TOOLCHAIN_CONFIG because
it needs kernel headers >= 3.14. So use an updated version of it,
copying the config fragment from
support/config-fragments/autobuild/br-arm-full.config
Signed-off-by: Ricardo Martincoski <ricardo.martincoski@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Use the new builtin kernel 4.19 with VirtIORNG to provide entropy to
test syslog-ng.
Signed-off-by: Ricardo Martincoski <ricardo.martincoski@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
More and more packages being tested by the test infra, e.g. syslog-ng,
need entropy at startup, usually reading from /dev/random.
Some test cases can also depend on a kernel version newer than the
builtin ones already provided by the test infra:
- 3.11.0 for armv5;
- 4.0.0 for armv7.
Add a new builtin kernel to be used by such test cases.
Add it for armv5 so most test cases that switch to use this kernel can
keep using BASIC_TOOLCHAIN_CONFIG.
Use the same kernel version and kernel config as qemu_arm_versatile plus
HW_RANDOM_VIRTIO for VirtIORNG to be usable.
Copy the actual binary file from the syslog-ng runtime test at current
master @ 29e1cb8884.
Since there is already a 'kernel-versatile' file on autobuild.buildroot.net
and we must keep it with this name for reproducibility purposes, create a
simple naming convention for newer builtin kernel images and dtb files:
kernel-<defconfig>-<kernel_series_version>
<dtb_name>-<kernel_series_version>.dtb
Pass '-device virtio-rng-pci' to qemu when this kernel is used.
Signed-off-by: Ricardo Martincoski <ricardo.martincoski@gmail.com>
Cc: Arnout Vandecappelle <arnout@mind.be>
Cc: Peter Korsgaard <peter@korsgaard.com>
Cc: Romain Naour <romain.naour@gmail.com>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
[Peter: use this new kernel instead of the old builtin/armv5 kernel]
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Fixes CVE-2018-18310: An invalid memory address dereference was
discovered in dwfl_segment_report_module.c in libdwfl in elfutils
through v0.174. The vulnerability allows attackers to cause a denial of
service (application crash) with a crafted ELF file, as demonstrated by
consider_notes.
Fixes CVE-2018-18520: An Invalid Memory Address Dereference exists in
the function elf_end in libelf in elfutils through v0.174. Although
eu-size is intended to support ar files inside ar files,
handle_ar in size.c closes the outer ar file before handling all inner
entries. The vulnerability allows attackers to cause a denial of service
(application crash) with a crafted ELF file.
Fixes CVE-2018-18521: Divide-by-zero vulnerabilities in the function
arlib_add_symbols() in arlib.c in elfutils 0.174 allow remote attackers
to cause a denial of service (application crash) with a crafted ELF
file, as demonstrated by eu-ranlib, because a zero sh_entsize is
mishandled.
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Since version 1.5, mosquitto can be built with explicit support for
systemd. If enabled, libmosquitto will link against libsystemd: when
started, the mosquitto broker notifies systemd that it is ready (ie.
initialized and ready to accept connections), so that services that
depend on the mqtt broker can be started only at that point.
To enable this feature, the systemd service config file needs to change
to Type=notify. Upstream now provides such a file, so we can remove
ours.
Signed-off-by: Titouan Christophe <titouan.christophe@railnova.eu>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Since version 1.5, it is possible to build mosquitto as a static lib.
However, the broker still needs a toolchain with support for shared libraries,
because it contains code to dynamically load modules at runtime. This
code makes use of dlfcn.h, which is only available for dylib enabled
systems.
Signed-off-by: Titouan Christophe <titouan.christophe@railnova.eu>
[Peter: adjust broker comment]
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
In commit a589325405
("support/config-fragments/autobuild: rename br-riscv64-musl config"),
the RISC-V 64-bit musl toolchain config snippet was renamed, but the
toolchain.csv file was not updated accordingly.
Due to this, utils/genrandconfig was no longer able to generate any
configuration.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Package prboom builds using -O2 flag ignoring Buildroot settings, this
is due to the fact that -O2 is appended at the end of compiler flags.
Remove -O2 from 'configure.ac' file and set PRBOOM_AUTORECONF to YES,
this way CFLAGS_OPTS will contain Buildroot TARGET_CFLAGS.
Signed-off-by: Giulio Benetti <giulio.benetti@micronovasrl.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
BR2_TOOLCHAIN_HAS_GCC_BUG_85180 dependency is already satisfied because
BR2_PACKAGE_BOOST_FIBER depends on
BR2_PACKAGE_BOOST_CONTEXT_ARCH_SUPPORTS that doesn't contain
BR2_microblaze and BR2_TOOLCHAIN_HAS_GCC_BUG_85180 depends right on
BR2_microblaze. So let's remove 'depends on
BR2_TOOLCHAIN_HAS_GCC_BUG_85180'.
Signed-off-by: Giulio Benetti <giulio.benetti@micronovasrl.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Package libnss had a BR2_TOOLCHAIN_HAS_GCC_BUG_85862 dependency and
since ecryptfs-utils depends on libnss it does have this dependnecy as
well.
However, gcc bug 85862 has been worked around now in libnss by
disabling optimization, so libnss no longer has this
BR2_TOOLCHAIN_HAS_GCC_BUG_85862 dependency. We can therefore drop it
from ecryptfs-utils as well.
Signed-off-by: Giulio Benetti <giulio.benetti@micronovasrl.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
With Microblaze Gcc version < 8.x the build hangs due to bug 85862:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85862
To avoid this, the libnss package has a !BR2_TOOLCHAIN_HAS_GCC_BUG_85862
dependency. However, gcc bug 85862 only triggers when optimization is
enabled, so we can work around the issue by passing -O0, which is what
we do in other Buildroot packages to work around this bug.
Signed-off-by: Giulio Benetti <giulio.benetti@micronovasrl.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
With a C library which does not provide fenv.h, it won't work at runtime:
Crash after an "import numpy" on python.
Since numpy v1.16.0:
"Alpine Linux (and other musl c library distros) support
We now default to use fenv.h for floating point status error reporting.
Previously we had a broken default that sometimes would not report
underflow, overflow, and invalid floating point operations. Now we can
support non-glibc distrubutions like Alpine Linux as long as they ship
fenv.h."
Disable python-numpy for uClibc to avoid the runtime errors.
ARC's glibc used to have an incomplete fenv.h, but this has been fixed
since commit be0aaaaecd ("toolchain: bump ARC tools to arc-2019.03
release"), so we don't need an exception for ARC.
Two patches attempted to fix the build for uclibc and glibc for ARC, but
didn't fix the runtime issue. Remove those patches.
Signed-off-by: Damien DUVAL <damien.duval@smile.fr>
Signed-off-by: Alexandre PAYEN <alexandre.payen@smile.fr>
Cc: Alexey Brodkin <Alexey.Brodkin@synopsys.com>
Signed-off-by: Romain Naour <romain.naour@smile.fr>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Qt5 has predefined optimization flags depending if you're building for
size, for debug etc. These flags are defined in
mkspecs/common/gcc-base.conf:
QMAKE_CFLAGS_OPTIMIZE = -O2
QMAKE_CFLAGS_OPTIMIZE_FULL = -O3
QMAKE_CFLAGS_OPTIMIZE_DEBUG = -Og
QMAKE_CFLAGS_OPTIMIZE_SIZE = -Os
Then, in common/features/default_post.prf, they add those flags to
QMAKE_CFLAGS_RELEASE/QMAKE_CXXFLAGS_RELEASE depending on various build
options (optimize_size, optimize_full, optimize_debug):
optimize_size {
!isEmpty(QMAKE_CFLAGS_OPTIMIZE):!isEmpty(QMAKE_CFLAGS_OPTIMIZE_SIZE) {
QMAKE_CFLAGS_RELEASE -= $$QMAKE_CFLAGS_OPTIMIZE
QMAKE_CXXFLAGS_RELEASE -= $$QMAKE_CFLAGS_OPTIMIZE
QMAKE_CFLAGS_RELEASE += $$QMAKE_CFLAGS_OPTIMIZE_SIZE
QMAKE_CXXFLAGS_RELEASE += $$QMAKE_CFLAGS_OPTIMIZE_SIZE
}
} else: optimize_full {
!isEmpty(QMAKE_CFLAGS_OPTIMIZE):!isEmpty(QMAKE_CFLAGS_OPTIMIZE_FULL) {
QMAKE_CFLAGS_RELEASE -= $$QMAKE_CFLAGS_OPTIMIZE
QMAKE_CXXFLAGS_RELEASE -= $$QMAKE_CFLAGS_OPTIMIZE
QMAKE_CFLAGS_RELEASE += $$QMAKE_CFLAGS_OPTIMIZE_FULL
QMAKE_CXXFLAGS_RELEASE += $$QMAKE_CFLAGS_OPTIMIZE_FULL
}
}
Since this default_post.prf is included *after* our qmake.conf file,
these flags override our optimizations flags, which is not good.
However, our qmake.conf file is included *after* gcc-base.conf, so we
can simply reset those variables to have the empty value, and our
optimization flags will be used.
Signed-off-by: Giulio Benetti <giulio.benetti@micronovasrl.com>
[Thomas: completely change the approach, by simply resetting the
QMAKE_CFLAGS_OPTIMIZE_* variables in qmake.conf]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
In qmake.conf.in has been left 'QMAKE_CXXFLAGS_RELEASE += -O3' but this
leads to not use Buildroot CXXFLAGS when building in release
mode(without debugging symbols). So let's remove it to let Qt5 to follow
Buildroot optimization flags like other packages do.
Signed-off-by: Giulio Benetti <giulio.benetti@micronovasrl.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
sshguard protects hosts from brute-force attacks against SSH and other
services.
Signed-off-by: Angelo Compagnucci <angelo@amarulasolutions.com>
[Peter: cleanup, start init script at S49, correct license, select iptables]
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Includes the newest firmware as shipped by Raspbian Buster,
the Raspbian release designed for the Pi4
Signed-off-by: Michael Cullen <michael@michaelcullen.name>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
