And use the wide API for pure is-env-variable-set checks too, as the
first call to a narrow env API function would lead to the C runtime
preparing and maintaining both narrow and wide environments.
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).
... to -link-defaultlib-debug (with alias for backwards compatibility).
-link-defaultlib-shared is to be used for switching between static and
shared default libs to be linked with.
It defaults to true when generating shared libraries (if shared
druntime/Phobos are supported for the target, i.e., not for Windows).
This is a benign breaking change!
`global.params.optimize` is never changed from its initial `false` state.
When experimentally enabling it, the MS linker produces warnings like
LINK : /LTCG specified but no code generation required; remove /LTCG from
the link command line to improve linker performance
The default MS C runtime library doesn't depend on the `LINK_WITH_MSVCRT`
CMake variable anymore.
The user can freely choose among the 4 variants libcmt[d] / msvcrt[d] via
-mscrtlib or choose between static/dynamic release variant via -static.
LDC keeps on defaulting to the static release C runtime, so
`-static=false` or `-mscrtlib=msvcrt[d]` must be used explicitly in order
to link against the runtime DLLs.
For invoking MS tools such as link.exe and lib.exe, which require
compatible PATH, LIB, LIBPATH etc.
We previously wrapped the invokation of the tool with a batch file taking
care of setting up the environment and then calling the actual tool.
I changed this to first invoke another batch file setting up its
environment and then dumping all environment variables to a file. LDC then
parses this file and updates its own environment variables. Later spawned
child processes then inherit the updated environment, and the tools will
be located by LLVM in updated PATH.
This allows LDC to keep track of the used Visual C++ installation (and
could so set up additional runtime libs required since VS 2015, something
we would have needed some time back when we still supported VS 2013). It's
also required as a prerequisite for integrating LLD as in-process linker
on Windows.
I quickly looked into the option of setting up the environment manually,
but the MS batch files are full of quirks, mixtures of registry and
file-system lookups, checking for existence of misc. headers to filter out
bogus installations etc. With VS 2017, there's nothing in the registry at
all anymore (at least for the Build Tools); MS expose a COM interface for
querying the VS installer... But at least they still provide the batch
files.
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.
Let LDC treat relative output paths as relative to the current working
directory again (as it always used to until a few weeks ago). It's more
intuitive and avoids breaking build systems/scripts using LDC directly.
Only LDMD continues to prepend the -od directory to the relative output
path, for DMD compatibility.
Fixes issue #1819.
Make sure the overall order corresponds to the user's command-line order
of object and source files. The only exception being singleObj builds,
for which the single object file for all source files is always the first
entry in the object files list (which is forwarded to the linker in that
order). This is done so that we can easily get hold of the name when
emitting the single object file later in the `ldc::CodeGenerator` dtor.
It should also clearly define the linking order (affecting comdat
selections etc.) for special singleObj builds.
Also reuse some more code (wrt. output filenames) from DMD's main().
