On Thursday, 10 August 2017 at 16:05:07 UTC, Johan wrote:>
On Thursday, 10 August 2017 at 14:32:04 UTC, Adam D. Ruppe wrote:>
On Wednesday, 9 August 2017 at 22:43:03 UTC, Johnson Jones wrote:>
because people cannot cut ties with the past and learn from their mistakes. Do we even need to separate the linker and compiler?
Like I said though, a lot of D's corporate users see this as being a major feature for their productivity. So it isn't quite as clear cut that one way is better than the other.
Separating compilation and linking is helpful for example for reducing the build time of incremental builds and parallelizing builds. A number of language semantics I personally understand in terms of separate codegen and linking, but I am not sure if that's strictly needed (D being a systems language, probably it is). Separate compilation is also needed for cross-language interop (e.g. for a mixed C++/D codebase).>
But Walter has said he is interested in doing an integrated linker and getting benefits from it, just that's a lot more work than it sounds like and he has a lot of other things to do...
Kinke has added LLD to LDC for MSVC, and for other platforms it is a WIP. See https://github.com/ldc-developers/ldc/pull/2142 , https://github.com/ldc-developers/ldc/pull/2203 . So already LDC running on Linux can generate a Windows executable.
I have been struggling with this same linking problem.
I have a library folder with *.o files that I compiled into a static library: mylibrary.a
In this folder, I have a package.d that publicly imports all the .d sources in that folder (as is recommended).
I compile an application in the main folder as follows:
dmd -I=mylibrary mylibrary/mylibrary.a application.d
Initially, this worked fine, but, at some point after adding stuff to the library, I started having the aforementioned linking problem.
For me, the problem was fixed when I compiled package.d into package.o (dmd -c package.d) and added it to the .a file.
I am guessing, for shared objects (.so files) you also need to add the package.o file to the library in order for it to include the reference to moduleInfo.
Note that compiling the same program with
dmd application.d mylibrary/*.d
also works, because that includes the package.d file. If package.d is omitted from the list you get the exact same ld: undefined reference to _...._ModuleInfoZ