I posted this on stackoverflow, but it doesn't seem like anyone knows what is going on:

I'm writing an application in D which interfaces with OpenGL and a few other native libraries (using the Derelict libraries). However, this error does not seem to relate to that at all.

Whenever I do "dub build" the compilation succeeds, but ld fails with this message:

Linking...
../git/mango-engine/bin/libmango-engine.a(gl_model_503_284.o):(.data._D12mango_engine8graphics6opengl8gl_model7GLModel6__initZ+0x10):     undefined reference to `internal'
../git/mango-engine/bin/libmango-engine.a(shader_51b_52f.o):    (.data._D12mango_engine8graphics6shader13ShaderProgram6__initZ+0x18):     undefined reference to `internal'
collect2: error: ld returned 1 exit status

I have no idea what this means, and have never seen it before. Also, strangely this error only occurs when I import the specific files: gl_model.d and shader.d, from another DUB project. If they are not imported the linker succeeds.

I'm not sure what information to provide, so I will just link the whole source code: https://github.com/jython234/mango-engine

On 10/10/2016 12:23 PM, jython234 wrote:
> ld fails with this message:
>
> Linking...
> ../git/mango-engine/bin/libmango-engine.a(gl_model_503_284.o):(.data._D12mango_engine8graphics6opengl8gl_model7GLModel6__initZ+0x10):
> undefined reference to `internal'
> ../git/mango-engine/bin/libmango-engine.a(shader_51b_52f.o):
> (.data._D12mango_engine8graphics6shader13ShaderProgram6__initZ+0x18):
> undefined reference to `internal'
>
> I have no idea what this means, and have never seen it before.

A symbol remains undefined after all input files, including libraries, had been processed. Common causes for this are:

A function was called in your code, but the function was never written.

A virtual function was declared, but never written.

A data variable was referenced, but never defined anywhere.

Did not specify all the .obj files to the linker.

The calling conventions of the function being referenced do not match the calling conventions of the defined function. Compiler switches, memory models, and special keywords can all affect calling convention (and thereby the name of the symbol as it appears in the .obj file).

One or more missing library files (.lib). One way to figure out which .lib file contains the missing symbol is to run:

\dm\bin\grep symbolname \dm\lib\*.*

The LIB environment variable is missing or not pointing to the \dm\lib directory or wherever the .lib files reside.

I've tracked it down to two lines (which are the same):

private SyncLock lock = new SyncLock();

SyncLock is just an empty class which I use to construct objects for use in "synchronized" blocks (not sure if this is the right way to do this). Apparently if I move the initialization to the constructor there are no linker errors.

On 10/10/2016 3:20 PM, jython234 wrote:
> I've tracked it down to two lines (which are the same):
>
> private SyncLock lock = new SyncLock();
>
> SyncLock is just an empty class which I use to construct objects for use in
> "synchronized" blocks (not sure if this is the right way to do this). Apparently
> if I move the initialization to the constructor there are no linker errors.

You can use obj2asm to examine the object files to see what is different between the two cases.