This uses LLVM's TimeProfiler functionality, such that LLVM's work is traced in the same profile (optimization and machine code gen).
Functionality is meant to be identical to Clang and LLD's --ftime-trace.
LDC currently silently ignores all passed lib files when linking for a static library, but dmd doesn't.
Current proposal makes LDC match DMD's behavior and link the libraries together.
It seems to be hitting non-ENOENT when trying to open a non-existent
target library, although the error code's message is 'No such file or
directory'. - Prefer an exists() check instead of relying on an exact
error code.
This is what DMD does and crucial for `ldmd2 -od=objects foo.d` with
relative -od path (and no -of). The object file path will be
`objects/foo.o[bj]`. As it's relative, LDC used to prepend the objects
dir (again) in LDMD mode, resulting in the inferred executable file name
`objects/objects/foo[.exe]`.
So while this is a breaking change, it fixes DMD compatibility of LDMD
and makes a lot of sense for 'pure' LDC too IMO (use the first object's
file name, replace the extension and save it in the working dir, not in
the directory containing the first object file).
This fixes the dmd-testsuite regressions with relative RESULTS_DIR and
a few long-standing non-fatal dmd-testsuite errors (failing file
removals).
Results in a 7.5% bigger RelWithDebInfo ldc2.exe on Win64 with LLVM 3.9.1.
LLD is currently enforced when building with LDC_WITH_LLD=ON. And LLD
still doesn't support debuginfo (.pdb) generation for MSVC targets.
By directly integrating LLVM's `llvm-lib.exe` driver to generate static
libs for MSVC targets and a stripped-down version of the `llvm-ar` tool
for the other targets.
Introduce command-line option `-archiver=<file>` to allow the user to
specify an external archiver to be invoked.
