Fedora has recently migrated to wget2, which has dropped ftp support and the
--passive-ftp command line option:
https://fedoraproject.org/wiki/Changes/Wget2asWget
It turns out that the command line option also doesn't do anything for wget1
as it was made the default in wget 1.10:
https://git.savannah.gnu.org/cgit/wget.git/tree/NEWS?h=v1.13#n292
wget 1.10 is from 2005, so it is safe to assume that all supported
distributions use >= 1.10.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
(cherry picked from commit 1a61c1d9b1)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Fix the following build failure raised since commit
32c1fbad55:
configure: error: *** A compiler with support for C++17 language features is required.
Fixes: 32c1fbad55
- http://autobuild.buildroot.org/results/451bae7151a74cbcb5d199b8516e9c255a0953fe
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
[Arnout: also update BR2_GOOGLE_BREAKPAD_ENABLE]
Signed-off-by: Arnout Vandecappelle <arnout@mind.be>
(cherry picked from commit 109362c904)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Historically, Buildroot has defaulted to -Os as the gcc optimization
flags. However, this default is probably not the most appropriate
anymore, and this commit therefore changes the default to -O2.
Here are some arguments in favor of this change:
- Most Buildroot users use Buildroot for platforms that have a
reasonable amount of storage, and the difference between -Os and -O2
in terms of code size is no longer as significant compared to the
size of storage available on average embedded Linux devices
typically found these days.
- -Os can have a pretty bad performance impact, compared to -O2.
- -Os is much less widely tested than -O2. For example, with recent
versions of gcc, there are parts of Qt5 that segfault when compiled
with -Os and work perfectly fine with -O2. Yes, it's a compiler bug
that should be fixed, but in the mean time, having a default that's
more widely used/tested makes sense.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Acked-by: Yann E. MORIN <yann.morin.1998@free.fr>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
BR2_DOWNLOAD_FORCE_CHECK_HASHES currently has the following
dependency:
depends on BR2_GLOBAL_PATCH_DIR != ""
However, strictly speaking checking all hashes does not necessarily
require using BR2_GLOBAL_PATCH_DIR, as long as you don't use custom
versions.
But more importantly:
- Having this dependency means that this options is hidden when people
don't use BR2_GLOBAL_PATCH_DIR. Instead the option should always be
made visible, encouraging people to turn it on.
- The Config.in comment was there to mitigate this previous argument,
but this comment then shows up all the time when you have an empty
global patch dir.
This seems over-complicated, and it sounds much easier to have the
option unconditionally available, and visible, and clarify in its help
text that in order to this to work fully with custom package versions,
BR2_GLOBAL_PATCH_DIR can be used to provide extra hash files.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
[yann.morin.1998@free.fr:
- fix typo noticed by Peter K.
- reword kast sentence after review by Peter K.
]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
The google-breakpad package uses stab.h which is not included in
uClibc, causing the following build error:
src/common/stabs_reader.cc:37:10: fatal error: stab.h: No such file or directory
37 | #include <stab.h>
| ^~~~~~~~
compilation terminated.
Fixes:
http://autobuild.buildroot.net/results/bba513b7c63a24a83805d2b989a9b95e5fe08e82/
Signed-off-by: Adam Duskett <adam.duskett@amarulasolutions.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Currently, when a package is downloaded from a custom location or
version, Buildroot excludes such a package from the mandatory integrity
check with hashes, because it was until now not possible to have such
hashes.
We now have a mechanism which users can leverage to provide additional
hashes, and so custom versions or locations can now be checked too.
Buildroot has no way to know that hashes have indeed been provided for
a custom location/version, and so will still happily ignore an
unchecked package.
However, users who do provide extra hashes most probably do expect that
no download is done without an integrity check, and thus expect that a
missing hash not be ignored.
Add an option that users can select to make Buildroot forcibly require
at least one valid hash, and no invalid hash, for all downloads.
Reported-by: "Martin Zeiser (mzeiser)" <mzeiser@cisco.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Currently, we expect and only use hash files that lie within the package
directory, alongside the .mk file. Those hash files are thus bundled
with Buildroot.
This implies that only what's known to Buildroot can ever get into those
hash files. For packages where the version is fixed (or a static
choice), then we can carry hashes for those known versions.
However, we do have a few packages for which the version is a free-form
entry, where the user can provide a custom location and/or version. like
a custom VCS tree and revision, or a custom tarball URL. This means that
Buildroot has no way to be able to cary hashes for such custom versions.
This means that there is no integrity check that what was downloaded is
what was expected. For a sha1 in a git tree, this is a minor issue,
because the sha1 by itself is already a hash of the expected content.
But for custom tarballs URLs, or for a tag in a VCS, there is indeed no
integrity check.
Buildroot can't provide such hashes, but interested users may want to
provide those, and currently there is no (easy) way to do so.
We leverage the existing global-patch-dir mechanism to look for extra
hash files. We use the same heuristic that is used for bundled hash
files, and for each global patch directory <dir>, we use the first file
to exist among:
1. look into <dir>/<package>/<version>/<package>.hash
2. look into <dir>/<package>/<package>.hash
Reported-by: "Martin Zeiser (mzeiser)" <mzeiser@cisco.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
NodeJS 20 requires gcc >= 10.1. Unfortunately, except for
BR2_HOST_GCC_AT_LEAST_4_9, Buildroot only handles host gcc version
with the granularity of the major release, so we will have to round up
to GCC >= 11 for NodeJS 20.
Signed-off-by: Adam Duskett <adam.duskett@amarulasolutions.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Now that we have HTTPS support for sources.buildroot.net (through Lets
encrypt / Cloudflare), it makes sense to default to it for our backup site.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Y2038 is now almost only 15 years away, and embedded systems built
today are potentially going to still be operational in 15 years, and
even though they are supposed to receive updates by then, we all know
how things go, and potentially some of these embedded systems will not
receive any update.
In 2038, the signed 32-bit representation of time_t used on 32-bit
architectures will overflow, causing all time-related functions to go
back in time in a surprising way.
The Linux kernel has already been modified to support a 64-bit
representation of time_t on 32-bit architectures, but from a C library
perspective, the situation varies:
- glibc uses this 64-bit time_t representation on 32-bit systems
since glibc 2.34, but only if -D_TIME_BITS=64 is
specified. Therefore, this commit adds an option to add this flag
globally to the build, when glibc is the C library and the
architecture is not 64-bit.
- musl uses unconditionally a 64-bit time_t representation on 32-bit
systems since musl 1.2.0. So there is nothing to do here since
Buildroot has been using a musl >= 1.2.0, used since Buildroot
2020.05. No Buildroot option is needed here.
- uClibc-ng does not support a 64-bit time_t representation on 32-bit
systems, so systems using uClibc-ng will not be Y2038 compliant, at
least for now. No Buildroot option is needed here.
It should be noted that being Y2038-compliant will only work if all
application/library code is correct. For example if an
application/library stores a timestamp in an "int" instead of using
the proper time_t type, then the mechanisms described above will not
fix this, and the application/library will continue to be broken in
terms of Y2038 support.
Possible discussions points about this patch:
- Should we have an option at all, or should we unconditionally pass
-D_TIME_BITS=64, like we have been doing for _FILE_OFFSET_BITS=64
for quite some time. The reasoning for having an option is that
the mechanism is itself opt-in in glibc, and generally relatively
new, so it seemed logical for now to make it optional as well in
Buildroot.
- Should we show something (a Config.in comment?) in the musl and
uClibc-ng case to let the user know that the code is Y2038
compliant (musl) or not Y2038 compliant (uClibc-ng). Or should this
discussion be part of the Buildroot documentation?
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Current versions of sam-ba are 64bit only.
objdump -p $(HOST_DIR)/bin/sam-ba
$(HOST_DIR)/bin/sam-ba: file format elf64-x86-64
Signed-off-by: Daniel Lang <d.lang@abatec.at>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
When we introduced support for the paranoid check of unsafe libraries
and headers path with commit 4ac8f78d37 (Add option for paranoid
unsafe path checking) back in 2014, we made it optional, as we expected
that would break quite a few packages.
Now, almost 8 years later, we only have three packages that explicitly
reference the option (dillo, gnuradio, and libtalloc), either in a patch
or in their .mk.
The option has been enabled by default since 2016, with 61c8854cef
(toolchain: enable paranoid unsafe path check by default), and that has
not triggered many build failures in a while.
The minimal defconfig used by test-pkg has also had it enabled as of
b6c98b3549 (minimal.config: add BR2_COMPILER_PARANOID_UNSAFE_PATH=y)
in 2017.
It is time to make that globally unconditional now.
There is still a remnant, in our binutils patches. As our toolchain may
get used outside of Buildroot, people may got the expectation that path
poisoning is only a warning, so we keep the current behaviour.
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Cc: Romain Naour <romain.naour@gmail.com>
Acked-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
The http site automatically redirects to the https variant, so let's
just use that as the default.
The mirror list URL http://search.cpan.org/mirror seems outdated
(re-directed to https://metacpan.org/mirrors aka 'Not Found - The
resource you requested could not be found.').
The closest matching URLs we found were:
https://www.cpan.org/SITES.htmlhttp://mirrors.cpan.org/map.htmlhttp://mirrors.cpan.org/
That last one has all the list, so we use that; the second is a world
map, so we also include it.
Sadly, neither of the mirrors list (table or map) are served as https;
they are only available as http...
Signed-off-by: Peter Seiderer <ps.report@gmx.net>
[yann.morin.1998@free.fr:
- add a little blurb to explain http->https redirect
- update the mirror list URL, and...
- extend commit message with original explanations from Peter, and..
- notice that they are not served via https...
]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Many of the build options depend on the toolchain configuration. In
addition, it's pretty logical that you select first target architecture,
then the toolchain, and only then things like debug and pic/pie.
Therefore, move the "Toolchain" menu before the "Build options" menu
instead of after.
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Currently, glibc depends on !BR2_STATIC_LIBS in all the toolchain
variants.
However, for some architectures, glibc is the only supported libc. In
commit 3b3105328e ("Config.in: only
allow BR2_STATIC_LIBS on supported libc/arch"), we implemented a fix
to avoid configurations were BR2_STATIC_LIBS=y with an architecture
already supported by glibc, because these configurations are
impossible. This commit 3b3105328e
prevents from selecting BR2_STATIC_LIBS=y when the C library used for
the internal toolchain backend is glibc.
However, it introduces a discrepency between how this topic is handled
for internal and external toolchains:
- For internal toolchains, we prevent BR2_STATIC_LIBS=y if glibc is
chosen.
- For external toolchains, we allow BR2_STATIC_LIBS=y in all cases,
and it's each glibc toolchain that has !BR2_STATIC_LIBS
This commit addresses this discrepency by preventing BR2_STATIC_LIBS=y
if glibc is chosen in all cases.
Thanks to this, we can remove the !BR2_STATIC_LIBS dependency on both
the glibc package, and all glibc external toolchains.
Fixes: https://bugs.busybox.net/show_bug.cgi?id=14256
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
[Thomas: update to master, fix the gen-bootlin-toolchains script, add
a comment in the static/shared choice to indicate that static is
supported only with uclibc or musl]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Some packages have a configure option to enable LTO. Add a global option
to enable/disable this in packages.
Note that we could instead (or in addition) pass -flto directly to the
compiler in the toolchain wrapper, but that has a *much* bigger impact,
so for the time being let's not do that.
No toolchain dependency is added for this, because all toolchains now
support LTO.
- LTO support was merged in GCC years before 4.6 (our minimal version)
was released.
- Our oldest external toolchain, Sourcery ARM 2014.05, has LTO support.
- For our internal toolchains, it is supposedly regulated by
BR2_GCC_ENABLE_LTO. However, that option only *enables* it - it
doesn't disable LTO support when it's not provided. Since LTO support
defaults to enabled for a long time already in GCC, in practice all
Buildroot-generated toolchains do support LTO.
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
There is no need to have configuration files direbtly set the
BR2_PACKAGE_HOST_ELF2FLT option. The need for the elf2flt utility is
automatically determined by gcc build in package/gcc/gcc.mk according to
the BR2_BINFMT_FLAT option.
Accordingly, we can remove the file package/elf2flt/Config.in.host to
get rid of the BR2_PACKAGE_HOST_ELF2FLT option. BR2_STRIP_strip
dependency on this option is replaced with a dependency on
BR2_BINFMT_ELF.
To stay consistent with the fact that elf2flt supports only the arm, sh,
sparc, xtensa and riscv-64 architectures, a dependency on these
architectures is added to the BR2_BINFMT_FLAT option in arch/Config.in.
Board configuration files setting the BR2_PACKAGE_HOST_ELF2FLT option
are also updated.
Signed-off-by: Damien Le Moal <damien.lemoal@opensource.wdc.com>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Add Secure File Transfer Program (SFTP) support using a simple wrapper.
SFTP is a common protocol used to transfer files securely between
enterprises, but it is not currently supported in Buildroot because all
of the packages are usually available via HTTP, git or some other
download method.
SFTP is similar to FTP but it preforms all operations over an encrypted
SSH transport using a specific protocol. This is unlike ftps, which is
traditional FTP over an SSL/TLS connection.
Signed-off-by: Thomas Preston <thomas.preston@codethink.co.uk>
Signed-off-by: Michael Drake <michael.drake@codethink.co.uk>
[Arnout:
- update documentation with sftp everywhere scp is mentioned;
- rename "verbose" variable to "quiet";
- print the sftp command, similar to wget and scp helpers.
]
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
As reported by Toolchain-builder project [1], the microblaze glibc
toolchain creates a system that doesn't boot when FORTIFY_SOURCE is
enabled: the init process hangs.
Also, hardening features may not be wanted or possible for such
slow soft-core cpus [2].
Note: for completeness, BR2_RELRO_PARTIAL was manually tested and it
does boot.
[1] https://gitlab.com/bootlin/toolchains-builder/-/jobs/1467624500
[2] http://lists.busybox.net/pipermail/buildroot/2021-June/312416.html
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Cc: Giulio Benetti <giulio.benetti@benettiengineering.com>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
The nios2 architecture is already excluded from PIC/PIE due to issues,
and we're going to also exclude Microblaze, so let's introduce a
BR2_PIC_PIE_ARCH_SUPPORTS hidden boolean to facilitate adding this new
architecture exclusion.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Some packages have optional runtime assertions, extra traces, or other
elements that can help in debugging problems. However, such runtime elements
can negatively influence performance.
In a test program performing 100K gRPC calls from a client to a local server
and receiving the returned response, we see following execution time:
- runtime debug enabled: 1065 seconds
- runtime debug disabled: 48 seconds
This is more than a factor 20 (!) difference. Analysis shows that the
problem mostly stems from libabseil-cpp (a dependency of gRPC) which enables
mutex deadlock analysis when the preprocessor flag 'NDEBUG' is not set,
which adds a 'backtrace()' call on every lock/unlock. Potentially worse,
when libunwind is enabled and linked with the test program, 'backtrace()' is
not provided by glibc but by libunwind itself.
For production systems, users expect good performance out-of-the-box. In the
example above, the difference is huge and unless explicitly tested and
analyzed, users may not realize that the performance could be much better.
Address this problem by introducing a new option BR2_ENABLE_RUNTIME_DEBUG,
which can be used by packages or package infrastructures to set the
necessary flags.
Note that BR2_ENABLE_RUNTIME_DEBUG is orthogonal to BR2_ENABLE_DEBUG: the
former changes runtime behavior, while the latter is only expected to add
debug symbols to the build. Today, the cmake build system does introduce a
runtime impact when BR2_ENABLE_DEBUG is set, but that will be rectified in a
subsequent commit.
Signed-off-by: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com>
Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Reviewed-by: Yann E. MORIN <yann.morin.1998@free.fr>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Recently in Buildroot the option BR2_PIC_PIE has been enabled by default along
with other hardening features [1]. Since then the nios2 defconfig
qemu_nios2_10m50_defconfig is failing to boot due to a segfault in init program:
Run /init as init process
with arguments:
/init
with environment:
HOME=/
TERM=linux
Failed to execute /init (error -12)
See Buildroot build log and Qemu runtime test log in build artifacts [2].
Analyzing one of the binary with strace show that the problem occur
very early when starting the new process:
# strace ./busybox
execve("./busybox", ["./busybox"], 0x7f91ce90 /* 10 vars */) = -1 ENOMEM
(Cannot allocate memory)
+++ killed by SIGSEGV +++
Several binutils/glibc/gcc version has been tested without any success.
The issue has been reported to the glibc mailing list but it can be a linker
or kernel bug [3].
For the Buildroot 2021.05 release, disable BR2_PIC_PIE until the problem is
found and fixed.
Fixes:
https://gitlab.com/buildroot.org/buildroot/-/jobs/1285145889
[1] https://git.buildroot.net/buildroot/commit/?id=810ba387bec3c5b6904e8893fb4cb6f9d3717466
[2] https://gitlab.com/buildroot.org/buildroot/-/jobs/1285145889
[3] https://sourceware.org/pipermail/libc-alpha/2021-May/126912.html
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Cc: Yann E. MORIN <yann.morin.1998@free.fr>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Put back legacy comment for BR2_ENABLE_SSP which was dropped with commit
810ba387be
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Enhance security by enabling FORTIFY_SOURCE, PIC/PIE, RELRO and SSP by
default.
For SSP, SSP-all can have a significant impact on performance, so we do
not want to enable that unconditionally; instead we use SSP-strong if
available (since gcc-4.9), and resort to SSP-regular otherwise. People
who really, like really-really want to use SSP-all will still have to
enable it explicitly.
For FORTIFY, level 2 may change the behaviour of some glibc functions,
so may crash conforming programs, so may have adverse effects. As such,
we choose level 1 as the default, as it does not change the behaviour
of any function.
This could help making IoT more secure and fight against the assumption
that buildroot does not support binary hardening (see
https://cyber-itl.org/2019/08/26/iot-data-writeup.html)
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
[yann.morin.1998@free.fr:
- relax SSP to strong when available, regular otherwise
- extend commit log to explain why SSP-all is not used
- extend commit log to explain why FORTIFY level 2 is not used
]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Update label as suggested by Stéphane Veyret, as -Ofast is potentially
dangerous, and may break packages.
Fixes:
- https://bugs.buildroot.org/show_bug.cgi?id=13046
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Some packages requires support on the build machine to create gcc
plugins. This commit adds a blind option,
BR2_NEEDS_HOST_GCC_PLUGIN_SUPPORT, which such packages can
select. When this option is enabled, the logic in support/dependencies
verifies that everything needed on the build machine to build gcc
plugins is available.
Signed-off-by: Kamel Bouhara <kamel.bouhara@bootlin.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
With classpath removed, no packages select these symbols any more - So drop
them and their corresponding logic in dependencies.sh / genrandconfig.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
This commit implements the core of the move to per-package SDK and
target directories. The main idea is that instead of having a global
output/host and output/target in which all packages install files, we
switch to per-package host and target directories, that only contain
their explicit dependencies.
There are two main benefits:
- Packages will now see only the dependencies they explicitly list in
their <pkg>_DEPENDENCIES variable, and the recursive dependencies
thereof.
- We can support top-level parallel build properly, because a package
only "sees" its own host directory and target directory, isolated
from the build of other packages that can happen in parallel.
It works as follows:
- A new output/per-package/ directory is created, which will contain
one sub-directory per package, and inside it, a "host" directory
and a "target" directory:
output/per-package/busybox/target
output/per-package/busybox/host
output/per-package/host-fakeroot/target
output/per-package/host-fakeroot/host
This output/per-package/ directory is PER_PACKAGE_DIR.
- The global TARGET_DIR and HOST_DIR variable now automatically point
to the per-package directory when PKG is defined. So whenever a
package references $(HOST_DIR) or $(TARGET_DIR) in its build
process, it effectively references the per-package host/target
directories. Note that STAGING_DIR is a sub-dir of HOST_DIR, so it
is handled as well.
- Of course, packages have dependencies, so those dependencies must
be installed in the per-package host and target directories. To do
so, we simply rsync (using hard links to save space and time) the
host and target directories of the direct dependencies of the
package to the current package host and target directories.
We only need to take care of direct dependencies (and not
recursively all dependencies), because we accumulate into those
per-package host and target directories the files installed by the
dependencies. Note that this only works because we make the
assumption that one package does *not* overwrite files installed by
another package.
This is done for "extract dependencies" at the beginning of the
extract step, and for "normal dependencies" at the beginning of the
configure step.
This is basically enough to make per-package SDK and target work. The
only gotcha is that at the end of the build, output/target and
output/host are empty, which means that:
- The filesystem image creation code cannot work.
- We don't have a SDK to build code outside of Buildroot.
In order to fix this, this commit extends the target-finalize step so
that it starts by populating output/target and output/host by
rsync-ing into them the target and host directories of all packages
listed in the $(PACKAGES) variable. It is necessary to do this
sequentially in the target-finalize step and not in each
package. Doing it in package installation means that it can be done in
parallel. In that case, there is a chance that two rsyncs are creating
the same hardlink or directory at the same time, which makes one of
them fail.
This change to per-package directories has an impact on the RPATH
built into the host binaries, as those RPATH now point to various
per-package host directories, and no longer to the global host
directory. We do not try to rewrite such RPATHs during the build as
having such RPATHs is perfectly fine, but we still need to handle two
fallouts from this change:
- The check-host-rpath script, which verifies at the end of each
package installation that it has the appropriate RPATH, is modified
to understand that a RPATH to $(PER_PACKAGE_DIR)/<pkg>/host/lib is
a correct RPAT.
- The fix-rpath script, which mungles the RPATH mainly for the SDK
preparation, is modified to rewrite the RPATH to not point to
per-package directories. Indeed the patchelf --make-rpath-relative
call only works if the RPATH points to the ROOTDIR passed as
argument, and this ROOTDIR is the global host directory. Rewriting
the RPATH to not point to per-package host directories prior to
this is an easy solution to this issue.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
m68k does not seem to really support PIE as it raises the following
build failure with aer-inject:
/usr/lfs/hdd_v1/rc-buildroot-test/scripts/instance-1/output/host/opt/ext-toolchain/bin/../lib/gcc/m68k-buildroot-linux-uclibc/7.4.0/../../../../m68k-buildroot-linux-uclibc/bin/ld: /usr/lfs/hdd_v1/rc-buildroot-test/scripts/instance-1/output/host/m68k-buildroot-linux-uclibc/sysroot/usr/lib/Scrt1.o: in function `lib_main':
(.text+0x4): undefined reference to `__shared_flat_add_library'
/usr/lfs/hdd_v1/rc-buildroot-test/scripts/instance-1/output/host/opt/ext-toolchain/bin/../lib/gcc/m68k-buildroot-linux-uclibc/7.4.0/../../../../m68k-buildroot-linux-uclibc/bin/ld: final link failed: bad value
We also have another build failure with uclibc on microblazeel:
/home/buildroot/autobuild/instance-1/output-1/host/lib/gcc/microblazeel-buildroot-linux-uclibc/8.3.0/../../../../microblazeel-buildroot-linux-uclibc/bin/ld: final link failed: bad value
collect2: error: ld returned 1 exit status
Makefile.in:114: recipe for target '../utils/getconf' failed
So add a BR2_TOOLCHAIN_SUPPORTS_PIE dependency on BR2_PIC_PIE
Fixes:
- http://autobuild.buildroot.net/results/4cdd6f0368cc9d3c6e88f01b1a8929eb0839b638
- http://autobuild.buildroot.net/results/a82a484409149d7f9aff6140ddcb89f627f508c7
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Reviewed-by: Yann E. MORIN <yann.morin.1998@free.fr>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
... so we can drop all config options about it and previous versions.
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Arnout Vandecappelle <arnout@mind.be>
Cc: Peter Korsgaard <peter@korsgaard.com>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Cc: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Currently, the kconfig part contains two things: the kconfig option
with the paths to br2-external trees, and the kconfig menus for the
br2-external trees.
When we want to include more kconfig files from the br2-external tree
(e.g. to get definitions for pre-built toolchains), we will need to
have the paths defined earlier, so they can be used from the br2-external
tree to include files earlier than the existing menus.
Split the generated kconfig file in two: one to define the paths, which
gets included early in our main Config.in, and one to actually define
the existing menus, which still gets included at the same place they
currently are.
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>
In commit 7484c1c3b8 (toolchain/toolchain-wrapper: add BR2_RELRO_),
we added the PIC/PIE flags, but based on the RELRO_FULL condition.
It is however totally possible to do a PIC/PIE executable without
RELRO_FULL, as it is also valid to do a PIC/PIE build with RELRO_PARTIAL.
Add a new option that now governs the PIC/PIE flags.
Note: it is unknown if RELRO_FULL really needs PIC/PIE or not, so we
keep the current situation, where RELRO-FULL forces PIC/PIE compilation.
Decoupling can come later from an interested party.
Signed-off-by: "Yann E. MORIN" <yann.morin@orange.com>
Cc: Matt Weber <matthew.weber@rockwellcollins.com>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Cc: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com>
Reviewed-by: Matthew Weber <matthew.weber@rockwellcollins.com>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Currently, use of -fstack-protector-strong is only available for gcc
starting with 4.9, on the assumption that it appeared with that version.
Although this is true, it happens that quite a few vendors will have
back-ported -fstack-protector-strong to older gcc versions (at least 4.8
seen in the wild).
Remove the guard against gcc>=4.9, and expand the help text.
Note: we could have changed the guard to something like:
depends on BR2_TOOLCHAIN_GCC_AT_LEAST_4_9 || BR2_TOOLCHAIN_EXTERNAL_CUSTOM
However, the latest gcc we support in the internal toolchain now *is*
gcc-4.9, and similarly all external toolchains except Sourcery ARM are
4.9 or higher. So except for the Sourcery toolchain, the condition would
have always been true. For that one toolchain, we can allow it to hit
the SSP check, and just drop the condition entirely.
Signed-off-by: "Yann E. MORIN" <yann.morin@orange.com>
Cc: Matt Weber <matthew.weber@rockwellcollins.com>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Cc: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Currently, that file is generated rather late in the configuration
process, so BUILD_DIR is known (and exists) by then.
We're soon to generate that file much earlier, at a point where
BUILD_DIR is not yet known, so we have two options:
1- declare BUILD_DIR earlier;
2- generate the file in an already-known location.
We go with the second solution, as we're already generating a
br2-external related file in BASE_DIR, so we can as well generate all
br2-external files in the same place.
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>
Currently, we repeat all the SSP level selection deep down to the
toolchain wrapper itself, where we eventually translate it to the
actual SSP option to use. This is a bit redundant.
Additionally, we will want to check that the toolchain actually
supports that option (for those toolchain where it was backported).
So, move the translation into kconfig, and add the qstrip'ed value
to the additional flags passed to the wrapper. Add it before
user-supplied opitons, to keep the previous behaviour (and allow
anyone crazy-enough to override it with BR2_TARGET_OPTIMIZATION).
Signed-off-by: "Yann E. MORIN" <yann.morin@orange.com>
Cc: Matt Weber <matthew.weber@rockwellcollins.com>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Cc: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com>
Reviewed-by: Matthew Weber <matthew.weber@rockwellcollins.com>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
This commit adds a config option which will force buildroot to
build all host dependencies even if they are already present on the
host system. This may be a desirable option if different hosts are
used to build the same source. In this case, some packages will be
built on one host that are not built on another. This is problematic
if build source archives are cached afterwards for offline builds.
Cc: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Bryce Ferguson <bryce.ferguson@rockwellcollins.com>
Signed-off-by: Matt Weber <matthew.weber@rockwellcollins.com>
[Peter: reword, drop exit 1, reshuffle]
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The ssh command was added back in 2011 with commit c61788f09 (GENTARGETS:
add support for scp://) and was used to check that the remote file
existed, back when we supported 'make source-check'.
However, in 2017, with commit bf28a165d (pkg-{download, generic}: remove
source-check), we actually removed support for source-check.
The SSH command however was not removed then, and stuck, even though
nothing ever uses it It is not even exported in the environment, and scp
does not use it either (it has -S to specify an ssh-compatible program).
Get rid of it.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas De Schampheleire <patrickdepinguin@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
As reported in the bug report [1], gcc < 6 doesn't build when
FORTIFY_SOURCE is set to 1 or 2. The issue is related to the
upstream bug report [2] but the patch fixing the issue for gcc 6
has not been backported to earlier gcc versions.
Add a dependency on gcc at least version 6 to BR2_FORTIFY_SOURCE_1
and BR2_FORTIFY_SOURCE_2.
[1] https://bugs.busybox.net/show_bug.cgi?id=11476
[2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61164
[3] 55f12fce4c
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Cc: Matthew Weber <matthew.weber@rockwellcollins.com>
Cc: Peter Korsgaard <peter@korsgaard.com>
[Peter: only limit for internal toolchain as suggested by Matthew]
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
When we do a release, we know only of a set of gcc versions that the
host may have. But in the future, distributions with newer gcc versions
may show up.
Currently, we do not recognise those versions, and thus we do as if they
were older than the oldest we know of. This means that a set of packages
become unselectable, when they should be.
We fix that by capping the detected version to the highest we know of.
Reported-by: gargar_ on IRC
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Peter Korsgaard <peter@korsgaard.com>
Cc: Arnout Vandecappelle <arnout@mind.be>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Maxime Hadjinlian <maxime.hadjinlian@gmail.com>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
... to follow the convention: type, default, depends on, select, help.
Signed-off-by: Ricardo Martincoski <ricardo.martincoski@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
