| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
| |
Set up/Hard code STAGE2_SYSROOT to the root directory instead of
calculating it depending on the current directory because buildstream
has changed the default value of "build-root" directory and this was
causing issues in the stage2 packages.
See https://gitlab.com/BuildStream/buildstream/issues/414 for more information.
Bump also the SHA of bst-external to fcd1fc365d0250bffe02937c89dcc31d11c299cf
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This includes many fixes that result in us being able to produce a
minimal OS image or initramfs of a reasonable size. I have built an
initramfs of 16MB uncompressed with this change: still a bit bigger
than necessary, but much better than the comical ~700MB thing complete
with kernel source code and C++ compiler that I got before these
changes.
Note that the gnu-toolchain stack now puts all the toolchain binaries
into the 'devel' artifact. The 'runtime' artifact just contains
libraries needed to run programs that are built with that toolchain.
We should split this up further in future so that C programs don't
depend on libstdc++.
Special care is taken for GCC and GLIBC to handle the lib/ and lib64/
split that they do on some 64-bit platforms.
We also globally put /usr/src into the devel artifact, which is only
useful for the linux.bsp element at present but makes sense as a global
rule.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We intended to set the architecture triplet for systems we build
to something like x86_64-baserock-linux-gnu. This wasn't actually
happening though as nobody had passed the message on to the GCC and
Binutils build systems, so we got mixed defaults of
x86_64-pc-linux-gnu and x86_64-unknown-linux-gnu.
Both GCC and Binutils install files that have the target name
in their path, and it's useful when writing split rules if we
know in advance what that's actually going to be. Plus it looks
neater if we set the vendor field in the architecture triplet correctly!
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
| |
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 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.
|
| |
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|