| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The improvements are:
- use most of the default "Makefile" for standard packaging;
- also use the default ".gitignore" with for the derived assets;
- don't impose so many $CFLAGS on the user. GCC still needs to be given
the `-ffreestanding` flag explicitly for us to get a good binary;
- stop using ad-hoc tools/* scripts, and avoid the code-generation
anti-pattern overall on the build. Some of the generated files were
checked-in, and some were removed;
- remove empty files;
- use POSIX make(1) over gmake;
- add fuzz targets;
- partial "install" and "uninstall" targets;
- complete "clean" target.
The shortcomings are:
- only working on x86_64. More platforms coming soon;
- code is still messy: way too many warnings, GNU/BSD specific
extensions, inline assembly, and all kinds of unportable code;
- still only works with GCC and GCC-like compilers, and completly fails
with tcc(1) and cproc(1);
- the `deps.mk` file is being maintained manually. As I work on the
source files I'll finish automating its generation with `mkdeps.sh`;
- still seems to be coupled with Linux;
- still is missing tests setup;
- still uses `#include <$NAME.h>` instead of the correct
`#include "$NAME.h"` form.
The generated libgrovel.a did match the previous lib/libc.a 100%.
|
| | |
|
| |
|
|
|
| |
Since commit 2f853dd6b9a95d5b13ee8f9df762125e0588df5d, all generated
headers are generated under the obj directory, which is already ignored.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
this change adds support for building musl outside of the source
tree. the implementation is similar to autotools where running
configure in a different directory creates config.mak in the current
working directory and symlinks the makefile, which contains the
logic for creating all necessary directories and resolving paths
relative to the source directory.
to support both in-tree and out-of-tree builds with implicit make
rules, all object files are now placed into a separate directory.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
musl-clang allows the user to compile musl-powered programs using their
already existent clang install, without the need of a special cross compiler.
it achieves this by wrapping around both the system clang install and the
linker and passing them special flags to re-target musl at runtime.
it does only affect invocations done through the special musl-clang wrapper
script, so that the user setup remains fully intact otherwise.
the clang wrapper consists of the compiler frontend wrapper script,
musl-clang, and the linker wrapper script, ld.musl-clang.
musl-clang makes sure clang invokes ld.musl-clang to link objects; neither
script needs to be in PATH for the wrapper to work.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
the _concept_ of this wrapper has been tested extensively, but the
integration with the build/install system, and using a persistent
specfile rather than one generated at build-time, have not been
heavily tested and may need minor tweaks.
this approach should be a lot more robust (and easier to improve) than
writing a shell script that's responsible for trying to mimic gcc's
logic about whether it's compiling or linking, building shared libs or
executable files, etc. it's also lighter weight and should result in
mildly faster builds when using the wrapper.
|
|
|
I've had this around for a long time but somehow it never got
committed.
|
