add CLI options, -fLLVM, -fLLD, -fClang and their counterparts -fno-LLVM, -fno-LLD, -fno-Clang
#6251
Labels
Milestone
Comments
andrewrk
added
proposal
andrewrk
added a commit
that referenced
this issue
Sep 8, 2020
* std.cache_hash exposes Hasher type * std.cache_hash makes hasher_init a global const * std.cache_hash supports cloning so that clones can share the same open manifest dir handle as well as fork from shared hasher state * start to populate the cache_hash for stage2 builds * remove a footgun from std.cache_hash add function * get rid of std.Target.ObjectFormat.unknown * rework stage2 logic for resolving output artifact names by adding object_format as an optional parameter to std.zig.binNameAlloc * support -Denable-llvm in stage2 tests * Module supports the use case when there are no .zig files * introduce c_object_table and failed_c_objects to Module * propagate many new kinds of data from CLI into Module and into linker.Options * introduce -fLLVM, -fLLD, -fClang and their -fno- counterparts. closes #6251. - add logic for choosing when to use LLD or zig's self-hosted linker * stub code for implementing invoking Clang to build C objects * add -femit-h, -femit-h=foo, and -fno-emit-h CLI options
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
There are 3 configuration values here. The default value is for zig to automatically decide whether to use any of these three projects or to use its own implementations. These flags switch from the default value to override a forced choice.
By default, Zig will use its own backend for Debug builds, and LLVM for release builds. It will use its own linker code for Debug builds and LLD for release builds. It will also prefer LLD for linking when third party objects, libraries, or a linker scripts, or other advanced features are used that Zig's own linker does not support. For example when compiling C source files, Zig will prefer to use its own linker to write an object file, but then use LLD to link that together with the objects produced from compiling C source files. It will use Clang for
@cImportand compiling C source code, assembly files, preprocessor, and other miscellaneous things. However-fno-LLVMcould be used to force zig to make a release build without the LLVM backend, and likewise-fno-LLDcould be used to force Zig to always use its own linker (even if that would result in an error). Using-fno-Clangwill cause all translate-c and C compilation features to result in an error, unless the proposal to add a C frontend is accepted and implemented, in which case you can see how that would fit in here.For a zig compiler which does not have LLVM extensions compiled in, the automatic choice that zig will make for all 3 of these values is equivalent to if
-fno-LLVM,-fno-LLD,-fno-Clanghad been passed. Additionally passing these arguments redundantly is no problem and will have no effect.Passing
-fLLVM,-fLLD, or-fClangto a zig compiler which does not have LLVM extensions compiled in will result in an error message such as, "cannot use LLVM backend; compiler was not built with LLVM extensions enabled".The text was updated successfully, but these errors were encountered: