| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
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.
|
