| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
So we build the same systems in build-1 for ybd and buildstream
|
| |
|
|
|
|
|
|
|
|
|
| |
To hopefully fix a build issue that has randomly reared its head:
[3104/3492] Linking default/lib/tdb/tdbrestore
/usr/bin/ld: /usr/lib/gcc/x86_64-pc-linux-gnu/7.1.0/../../../libcom_err.a(error_message.o): relocation R_X86_64_32 against `.bss' can not be used when making a shared object; recompile with -fPIC
/usr/lib/gcc/x86_64-pc-linux-gnu/7.1.0/../../../libcom_err.a: error adding symbols: Bad value
collect2: error: ld returned 1 exit status
|
|
|
|
|
| |
This gains us support for `mkfs.ext4 -d`, which is great when making
disk images.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The approach from commit 56885a36e5c3830a6c6c7a663730a8a297a5825c was
neater, but it doesn't work due to this GitLab issue:
https://gitlab.com/gitlab-org/gitlab-ce/issues/20615
I can't see any way to make this work apart from putting the SHA1s
into the job before_script sections directly. I moved them upwards
to make it more obvious.
Of course once we stop using YBD we can clean this up nicely.
|
| |
|
|
|
|
|
| |
This version uses %{arch} instead of %{bst-arch}, and uses list
composition operations instead of pre- and post- commands.
|
|
|
|
|
|
|
|
|
|
|
|
| |
The initial implementation of architecture conditionals has been
removed, as the same behaviours can be implemented using the more
generic mechanism for conditionals that is being introduced for
BuildStream 1.0.
We now have two architecture options: build_arch and arch. They are
documented in project.conf. The first one controls the build sandbox
while the second controls the host and target of the binaries we
produce.
|
|
|
|
|
| |
This was meant to be added as part of MR !58, but of course I forgot
to `git add`.
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
Otherwise, cross builds can try and run a version of `ldconfig` that is
built for the target architecture rather than the host, resulting in
brokenness.
|
|
|
|
|
|
|
|
|
| |
This fixes cross-compilation of stage2-gcc against our stage3 base
sysroot.
If the `.la` files are not removed, Libtool insanity kicks in and we end
up with the x86_64 version of libstdc++ included in the cross-build
commandlines.
|
|
|
|
|
| |
This reduces the output size of bootstrap/stage3-sysroot.bst from 500MB
to 350MB.
|
| |
|
| |
|
| |
|
|\
| |
| |
| | |
sam/bootstrap-from-baserock-binaries
|
| |
| |
| |
| | |
Current master of all those
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| | |
We do want to control what version of BuildStream are we using in the CI,
not as part as the image; an update can break the build and the same commit
that built today can break tomorrow
This reverts commit 3de7f8086cfc89e11ffdf88651ab415e661e2609.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This replaces the previous approach of using the Freedesktop SDK binaries.
We need to support more architectures than just x86_32 and x86_64, and in
general it's better to bootstrap from a minimal sysroot that we build and
control.
The binaries are hosted at https://ostree.baserock.org/releases and are
produced by a manual (but automatable) process that I will document in
subsequent commits from the `bootstrap/stage3-sysroot.bst` element.
|
| |
| |
| |
| |
| |
| | |
The objcopy tool that we built in stage2 doesn't have zlib support, so
it can't handle the `--compress-debug-sections` flag that BuildStream
passes by default.
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
These each produce a minimal (~300MB) sysroot containing BusyBox, the
GNU C/C++ toolchain, and a couple of other components necessary for
bootstrapping Baserock reference systems from the ground up.
Morph and YBD used tools from the host to bootstrap, which usually
worked fine but was occasionally disasterous (such as when GLIBC
broke ABI between releases). BuildStream is more strict and requires
you to provide binaries to seed its sandbox.
The stage2 sysroot can only be used to build the stage3 sysroot, as
the stage2 components are configured with a non-standard /tools prefix
and the stage3 build instructions have some special casing that is
necessary to work with that.
The stage3 sysroot can be used to build pretty much anything and is
used to seed Baserock reference builds on each platform.
|
| |
|
|
|
|
|
| |
libseccomp has architecture-specific parts, and the previous version
did not support ppc64l.
|
|
|
|
|
|
| |
This is done because ppc64l is having compatibility problems.
The updated version of libffi depends on libtool.
|
|
|
|
|
|
|
|
|
|
|
|
| |
I got a seemingly random failure in CI:
https://gitlab.com/baserock/definitions/-/jobs/31214873
The log line with the actual error is cut off by BuildStream and I
can't reproduce the issue locally, but since it's clearly an
intermittent problem I can only put it down to the way BuildStream
sets MAKEFLAGS during the configure stage affecting the gnulib bootstrap
process (which does run `make` at one point).
|
| |
|
|
|
|
|
|
| |
It's better to use BuildStream arch conditionals than to use shell code,
because in the latter case any change will trigger rebuilds for all
architectures regardless of which ones it actually affects.
|
|
|
|
|
|
|
|
|
|
|
| |
We now have /tools at the *end* of the PATH rather than the start (which is
how it should have been all a long in stage 3) so glibc's configure
script will always find `bash` in /usr/bin before it looks in
/tools/bin.
This also fixes stage3 glibc building against a stage2 sysroot when there's
no symlink from /tools/bin -> /usr/bin. This is required for the current
cross-bootstrap method.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
We install the ld.so config to /etc/ld.so.conf in the stage2-glibc element,
but the ldconfig tool would look for /tools/etc/ld.so.conf. This caused no
problems for a long time, I suppose because we always built on top of
sysroots that had an existing /etc/ld.so.cache file. But if `ldconfig`
hadn't already been run in the sysroot, builds depending on stage2-glibc
would fail as various things would no longer be able to find libz.so due
the ldconfig command failing to find its config file.
|
|
|
|
|
|
|
|
|
|
|
| |
This is currently because fhs-dirs makes /lib a symlink to /usr/lib,
and buildstream mangles symlink paths from absolute paths to relative
paths.
The symlink ../tools/lib/libgcc_s.so ends up in /usr/lib, breaking
things.
This fixes that by explicitly installing the symlink to /usr/lib
|
|
|
|
| |
Needed to fix build on armv8
|
|
|
|
| |
Needed to fix build on ppc64.
|
|
|
|
| |
This means we no longer try to build syslinux on non-x86 platforms.
|
|
|
|
|
|
|
|
| |
The default behaviour of BuildStream is now for lists to overwrite
the previous value when composing them. In the fhs-dirs elements our
goal is extend the install commands in certain cases, so we now need
to use the (>) operator to cause it to append to the list instead of
overwriting.
|
|
|
|
|
|
|
|
|
|
|
|
| |
YBD scans the current working directory for definition files, which is
problematic now that we store hundreds of cached Git repos and OSTree
repos in a subdir of the definitions repo.
To avoid wasting loads of time calling stat() on tens of thousands of
directories, the cache is now in a hidden directory.
This depends on a change to YBD that causes it to efficiently ignore
hidden directories: https://gitlab.com/baserock/ybd/commit/6676c4ac0
|
| |
|
|
|
|
| |
This is hopefully what has been preventing BuildStream from pushing.
|
| |
|
| |
|
| |
|
|
|
|
|
| |
Removing since the docker image contains an installation of BuildStream
and is updated nightly (as pointed out by Sam).
|
|
|
|
|
| |
By default GitLab CI fetches and re-pushes cache, given deploy stages
won't cause the git repos to change, only fetch.
|
|
|
|
|
| |
By default, GitLab CI fetches the artifacts of all previous stages.
Be explicit about which artifacts we do and don't want.
|
| |
|
|
|
|
|
| |
Should we pick up the same runner in another job, artifacts will be
reused from this path.
|