| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
|
|
|
| |
This means we no longer try to build syslinux on non-x86 platforms.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
Currently this pulls the binaries from the Baserock artifact cache. This
is a temporary solution while we work out how to best to archive these
binaries permanently. (Probably in a separate OSTree repo, so that they
are excluded from any cache expiry algorithsm that might otherwise delete
them).
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
| |
It's unmaintained and probably unusable these days.
The baserock-import tool depends on Morph and has also been removed. Hopefully
it can one day start a new life as a BuildStream importer tool...
|
|
|
|
|
|
| |
This also updates OSTree to latest stable (2017.10), which is needed
for BuildStream, and updates Flatpak to latest which is needed for it to
build against the latest OSTree release.
|
| |
|
|
|
|
|
| |
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).
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
Change-Id: Ia72f4cc835fea6ecc72ab0704f877905f104bc40
|
|
|
|
| |
Change-Id: I767fc41d3336bb7a0fd14d74b7a7ee082ca03193
|
|
|
|
| |
Change-Id: Ifd32ee4809552bf52986431d48ed0e200d7f239d
|
|
|
|
|
|
|
|
|
|
|
| |
In order to bypass:
Cloning repository...
Cloning into '/builds/gitlab/omnibus-gitlab'...
error: RPC failed; curl 56 SSL read: error:00000000:lib(0):func(0):reason(0), errno 104
fatal: The remote end hung up unexpectedly
fatal: early EOF
fatal: index-pack failed
|
|
|
|
|
| |
We don't want to error out here, otherwise builds will only pass on
protected branches.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Builds with BuildStream are intermittently failing with a message like
this:
libtool: install: /usr/bin/install -c .libs/libsvn_delta-1.a /buildstream/install/usr/lib/libsvn_delta-1.a
libtool: install: chmod 644 /buildstream/install/usr/lib/libsvn_delta-1.a
libtool: install: ranlib /buildstream/install/usr/lib/libsvn_delta-1.a
libtool: install: /usr/bin/install -c .libs/libsvn_delta-1.lai /buildstream/install/usr/lib/libsvn_delta-1.la
/usr/bin/ld: cannot find -lsvn_delta-1
collect2: error: ld returned 1 exit status
libtool: install: /usr/bin/install -c .libs/libsvn_delta-1.a /buildstream/install/usr/lib/libsvn_delta-1.a
libtool: install: chmod 644 /buildstream/install/usr/lib/libsvn_delta-1.a
libtool: install: ranlib /buildstream/install/usr/lib/libsvn_delta-1.a
libtool: error: error: relink 'libsvn_ra_serf-1.la' with the above command before installing it
build-outputs.mk:1321: recipe for target 'install-serf-lib' failed
make: *** [install-serf-lib] Error 1
make: *** Waiting for unfinished jobs....
|
|
|
|
|
|
|
|
|
|
|
|
| |
The stage2 elements were all using the default strip-commands which
don't take into account the fact that we might be cross-compiling.
An `objcopy` build for one architecture will ignore binaries for
other architectures that it doesn't understand, so in practice no
stripping was taking place for the stage2 components when we were
doing cross-builds.
With this change, a stage2 sysroot containing just the 'runtime' and
'devel' domains has gone from 889MB to 306MB.
|
|
|
|
|
|
| |
The "downloadable" state is the one we need to special-case. The
"cached" state means that the artifact is cached *locally*, and
BuildStream will already avoid rebuilding it in this case.
|
|
|
|
|
|
|
|
|
|
|
| |
We shouldn't download artifacts to the CI workers every time somebody
pushes just to throw them away again. This should speed up no-op builds.
The functionality is implemented in two shell scripts. Context is here:
https://gitlab.com/BuildStream/buildstream/issues/77
It would be possible to do this with a single script, but I wanted to
avoid doing any argument parsing code in shell.
|
|
|
|
|
|
| |
This is a Fedora 26 image which has BuildStream's dependencies
pre-installed, which saves us waiting to `dnf install` everything
at the start of every CI job.
|
| |
|
|
|
|
|
|
|
| |
There hasn't been a release since v2.2.52, but there are fixes in
'master' which are useful. In particular the build system is now
standard Autotools, and it no longer breaks if /lib64 is a symlink
to /usr/lib64 (upstream commit cd76644ce9b9814a fixes that).
|
|
|
|
|
|
|
|
|
|
|
| |
This is required at least for armv8l64, otherwise the glibc.bst
element installs a symlink in /usr/lib/ld-linux-aarch64.so.2 that
points to a missing file (it expects /usr/lib64/ld-linux-aarch64.so.2
to exist, but if /lib64 is a directory rather than a symlink then
that file ends up only in the /lib64/ directory).
This also makes our filesystem hierarchy more consistent with other
GNU/Linux operating systems.
|
| |
|
| |
|
|
|
|
|
| |
We gained this file when we imported Tristan's gnu-toolchain project, we just
need to update it for building the Baserock reference systems.
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
sam/buildstream-autoconvert
This branch contains a manual conversion of the Baserock bootstrap
process to BuildStream. The original branch can be found here:
https://gitlab.com/BuildStream/buildstream-tests/tree/gnu-toolchain
It's not possible to automatically convert the existing Baserock
bootstrap due to differences in how BuildStream works.
|
| |\
| | |
| | |
| | |
| | | |
Update toolchain and allow cross-building
See merge request !9
|
| | | |
|
| | |
| | |
| | |
| | |
| | | |
We cannot do long GCC builds using the default GitLab CI runners, we'll
need to provide our own.
|
| | |
| | |
| | |
| | |
| | | |
This is primarly to avoid hitting the 1 hour timeout that seems to be
hardcoded into the CI system. It's also a bit clearer this way.
|
| | |
| | |
| | |
| | |
| | |
| | | |
With an empty cache, every worker must spend 10 minutes pulling all of
the sources that are required. There's no point having 5 workers pulling
the same things in parallel, so the first stage now contains only 1 job.
|
| | | |
|
| | | |
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This requires a feature recently added to BuildStream (in commit
03906221) that adds a framework for elements to support being
cross-compiled.
To build an armv8l64 native toolchain and sysroot on an x86_64 build
machine, for example, you can do this:
bst build --target-arch=armv8l64 gnu-toolchain/stage2.bst
You can then run `bst checkout` to get at the resulting binaries and
copy them onto an armv8l64 machine where they can be executed.
|
| | | |
|
| | | |
|
| |/ |
|
| |
| |
| |
| |
| |
| |
| | |
o Use the org.freedesktop.BasePlaform and org.freedesktop.BaseSdk
for building instead of the whole GNOME runtime.
o Some minor renames
|