ModuleInfo Error

[Steef Boerrigter]

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.
>
> -Johan

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