I've previously missed this part when moving to the DMD output filenames.
LDC used to enforce the target object file extension for all produced
objects.
So in `compilable/ldc_output_filenames.sh`, we tried to produce the object
file `myObj.myExt.` instead of `myObj.myExt`. The tests passed on Windows,
but failed at least on Linux.
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().
Introduce a hidden `-dwarf-version=<uint>` switch to support old gdb versions
used by Travis. Older versions only supporting DWARF-2 and/or not supporting
TLS correctly are detected in dmd-testsuite's CMakefile.
DMD does too, and the front-end's FileName class expects backslashes in
some places.
Due to the import and lib directories in the ldc2.conf file being
specified with forward slashes, most paths produced by LDC used both
slashes, e.g., `C:/LDC/ldc/runtime/druntime/src\object.d`, which looks
unprofessional, is problematic for the front-end and leads to differences
wrt. DMD when outputting module dependencies etc.
This reduces the size of a statically linked Phobos-based
Hello World by 11 kB on Linux x86_64.
Also creates a header file for gen/module.cpp, which has been
renamed to "modules" such as not to conflict with the frontend
header file.
Modern Linux distributions have their toolchain generate PIC code for
additional security features (like ASLR).
Since there is no (sane) way to detect whether the toolchain defaults to
PIC code, we simply default to PIC code on all Linux
distributions to avoid linking issues on these OSes.
The relocation model can be switched back to non-PIC code manually at
any time.
LLVM's ParseCommandLineOptions() expands response files automatically, but
always uses the TokenizeGNUCommandLine tokenizer, which apparently eats
backslashes.
The solution is to pre-expand the response files into the arguments vector
on the LDC side, and using TokenizeWindowsCommandLine if LDC is built for
Windows.
