@@ -21,37 +21,6 @@ pub fn opts() -> TargetOptions {
21
21
TargetOptions {
22
22
function_sections : true ,
23
23
linker : "link.exe" . to_string ( ) ,
24
- // When taking a look at the value of this `ar` field, one might expect
25
- // `lib.exe` to be the value here! The `lib.exe` program is the default
26
- // tool for managing `.lib` archives on Windows, but unfortunately the
27
- // compiler cannot use it.
28
- //
29
- // To recap, we use `ar` here to manage rlibs (which are just archives).
30
- // LLVM does not expose bindings for modifying archives so we have to
31
- // invoke this utility for write operations (e.g. deleting files, adding
32
- // files, etc). Normally archives only have object files within them,
33
- // but the compiler also uses archives for storing metadata and
34
- // compressed bytecode, so we don't exactly fall within "normal use
35
- // cases".
36
- //
37
- // MSVC's `lib.exe` tool by default will choke when adding a non-object
38
- // file to an archive, which we do on a regular basis, making it
39
- // inoperable for us. Luckily, however, LLVM has already rewritten `ar`
40
- // in the form of `llvm-ar` which is built by default when we build
41
- // LLVM. This tool, unlike `lib.exe`, works just fine with non-object
42
- // files, so we use it instead.
43
- //
44
- // Note that there's a few caveats associated with this:
45
- //
46
- // * This still requires that the *linker* (the consumer of rlibs) will
47
- // ignore non-object files. Thankfully `link.exe` on Windows does
48
- // indeed ignore non-object files in archives.
49
- // * This requires `llvm-ar.exe` to be distributed with the compiler
50
- // itself, but we already make sure of this elsewhere.
51
- //
52
- // Perhaps one day we won't even need this tool at all and we'll just be
53
- // able to make library calls into LLVM!
54
- ar : "llvm-ar.exe" . to_string ( ) ,
55
24
dynamic_linking : true ,
56
25
executables : true ,
57
26
dll_prefix : "" . to_string ( ) ,
0 commit comments