| Age | Commit message (Collapse) | Author |
|---|
|
|
|
There have been multiple reports of Xcode 14.0 (based on upstream LLVM
14) segfaulting when compiling `LibCore/Process.cpp`. Let's require
Xcode 14.3, which is a known good version based on LLVM 15.
Note that Xcode 14.3 requires macOS Ventura, so users of Monterey or
older are expected to get Homebrew Clang instead.
Homebrew Clang 13 also suffers from the same crash. Although I have not
tested on Linux, the backtrace points to the middle-end, so x86_64 is
also likely to be affected. LLVM 14 was released 14 months ago, so it's
not an unreasonable requirement.
|
|
This replaces the inline check for running as root with the common
method exit_if_running_as_root().
|
|
|
|
|
|
"image" was an alias for "qemu-image".
I want to add an `image` userland utility, which clashes with that
shortname.
So remove the existing "image" target. It was just an alias for
"qemu-image".
If you use serenity.sh to build, nothing changes. This only affects you
if you run ninja manually -- you now have to say `ninja qemu-image` to
build the disk image.
|
|
You may now, for example, run:
./Meta/serenity.sh run lagom ladybird https://serenityos.org
|
|
After 5ac57f9, we could no longer run "serenity.sh run lagom TestString"
because the TestString binary now lives in a subdirectory under
Build/lagom. Thus the existing method of running "$BUILD_DIR/TestString"
could not work.
This adds a "run-lagom-target" custom target to Lagom, to run a command
and pass arguments to that invocation. It turns out there really isn't a
"pretty" way of doing this with CMake or Ninja. But we can pass these as
environment variables for CMake to interpret. We just must be careful to
massage arguments into a CMake list.
|
|
|
|
This solution feels really hacky and should be refined later.
|
|
They currently reside under Build/<arch>, meaning that they would be
redownloaded for each architecture/toolchain build combo. Move them to a
location that can be re-used for all builds.
|
|
|
|
|
|
We previously disregarded Apple clang entirely, since no released
version was able to succesfully build Lagom. Xcode 14 seems to have
all the features we need, as we haven't added any code that needs
trunk clang features in quite a while.
|
|
|
|
We were checking the compilers against clang-12 and gcc-10. Since the
check itself is confusing, some comments are warranted.
|
|
So far we've gotten away with using GCC 11 for Lagom and to compile the
toolchain, but via #15795 we discovered a compiler bug that has been
fixed in the latest version but would error the build with CI's GCC 11.
Time for an upgrade :^)
We already use ubuntu-22.04 images in most places, so this is pretty
straightforward. The only exception is Idan's self-hosted runner, which
uses Ubuntu Focal. LibJS should build fine with GCC 11, still.
|
|
This ensures that the toolchain building scripts will use the host
toolchain that has been found manually, and that they won't fall back to
`cc` (which in the worst case may not even be installed).
|
|
|
|
This is a preparation to check if our users find noticeable bugs in the
x86-64 target, before we can decide if we want to remove the i686 target
for good.
|
|
|
|
Spelling fixes found by `codespell`.
|
|
|
|
|
|
|
|
Homebrew does not add upstream LLVM's install location to $PATH so as
not to conflict with XCode tools, so we should look for it by its
absolute path. LLVM is installed to /opt/homebrew/opt/llvm on ARM Macs,
and is a symlink that points to the latest stable LLVM version.
|
|
It's not a good idea, and it causes countless issues for people who
do so and then try to run without root later.
|
|
Previously, `serenity.sh rebuild-toolchain x86_64 clang` would simply
start building GCC instead and call it a day. With this change, if a
toolchain is passed as an argument, it is validated if it is either
"GNU" or "Clang" and exits with an error otherwise.
The `TOOLCHAIN` value defaults to the `SERENITY_TOOLCHAIN` environment
variable if not provided explicitly.
|
|
Various Clang binaries are now considered when choosing the compiler for
Lagom.
The selection precedence is as follows:
1. Use the compiler set via CC/CXX if it's a supported version
2. Use newest available GCC if it's supported
3. Use newest available Clang if it's supported
Note that Apple Clang is still not supported, as its versioning scheme
and the fact that it masquerades as both GCC and Clang would complicate
this logic even more.
Fixes #12253
|
|
I'm not sure when this changed, but the path is wildly different now.
|
|
This lets GDB resolve the kernel symbols correctly.
|
|
Because of ninja's default behavior of using all processors this gave
the correct behaviour because MAKEJOBS was empty. However this meant
that the processor count was printed to stderr when building.
|
|
The default behavior of using all cores will still apply if no
MAKEJOBS variable is supplied.
|
|
We now pass along the toolchain type to all subcommands. This ensures
that gdb will load the correct debug information for kernels compiled
with Clang, and the following warning won't appear with the GNU
toolchain:
> WARNING: unknown toolchain 'gdb'. Defaulting to GNU.
> Valid values are 'Clang', 'GNU' (default)
|
|
|
|
Also add a check to serenity.sh to ensure that the toolchain is new
enough for this feature to work.
|
|
Bump macOS CI version to macOS 11 while we're here.
|
|
egcc is the alias for the GCC compiler (since OpenBSD uses Clang by
default). Toolchain/BuildIt.sh has the necessary adjustments, but the
compiler check occurs before BuildIt.sh is called.
|
|
This is just silly :^)
$ serenity run lagom js
WARNING: unknown toolchain 'js'. Defaulting to GNU.
Valid values are 'Clang', 'GNU' (default)
|
|
'bootmode' now only controls which set of services are started by
SystemServer, so it is more appropriate to rename it to system_mode, and
no longer validate it in the Kernel.
|
|
Bootmode used to control panic behavior and SystemServer.
This patch factors panic behavior control into a separate flag.
|
|
Bootmode used to control framebuffers, panic behavior, and SystemServer.
This patch factors framebuffer control into a separate flag.
Note that the combination 'bootmode=self-test fbdev=on' leads to
unexpected behavior, which can only be fixed in a later commit.
|
|
With this, the subcommands 'addr2line` and `kaddr2line` work as with the
GNU toolchain.
|
|
This commit updates the Clang toolchain's version to 13.0.0, which comes
with better C++20 support and improved handling of new features by
clang-format. Due to the newly enabled `-Bsymbolic-functions` flag, our
Clang binaries will only be 2-4% slower than if we dynamically linked
them, but we save hundreds of megabytes of disk space.
The `BuildClang.sh` script has been reworked to build the entire
toolchain in just three steps: one for the compiler, one for GNU
binutils, and one for the runtime libraries. This reduces the complexity
of the build script, and will allow us to modify the CI configuration to
only rebuild the libraries when our libc headers change.
Most of the compile flags have been moved out to a separate CMake cache
file, similarly to how the Android and Fuchsia toolchains are
implemented within the LLVM repo. This provides a nicer interface than
the heaps of command-line arguments.
We no longer build separate toolchains for each architecture, as the
same Clang binary can compile code for multiple targets.
The horrible mess that `SERENITY_CLANG_ARCH` was, has been removed in
this commit. Clang happily accepts an `i686-pc-serenity` target triple,
which matches what our GCC toolchain accepts.
|
|
It's "Clang" (capitalized). Silently building gcc if the toolchain
isn't know seems a bit unfriendly. So print a warning for this
(and for other unknown toolchains).
|
|
If the superbuild created the lagom binary directory, it won't set
BUILD_LAGOM=ON in the CMake cache for that binary directory. Insert a
check into build_target() to make sure that if the user explicitly asks
for the lagom target, we have all our ducks in a row.
|
|
Direct build commands to the SuperBuild's binary directory, and
image/run commands to the Serenity binary directory.
As a side benefit, make the lagom target only build Lagom instead of the
entire OS alongside Lagom.
|
|
This allows us to step through the initial boot instructions.
|
|
This enables maintaining gcc and clang builds side-by-side.
|
|
|
