I'm running into some inexplicable linker errors when trying to compile a project.  I've tried two command lines to compile the project that I thought were equivalent except for the names of the output files:

// emptymain.d:
void main(){}

// test.d:
unittest {
    double[double] weights = [1:1.2, 4:2.3];
    import std.stdio;
    writeln("PASSED");
}

dmd -unittest emptymain.d test.d  // Linker errors

dmd -unittest test.d emptymain.d  // Works

Additionally, the linker errors only occur under a custom version of druntime.  Don't try to reproduce them under the stock version.  (For the curious, it's the precise heap scanning fork from https://github.com/rainers/druntime/tree/precise_gc2 .  I'm trying to get precise heap scanning ready for prime time.)

My real question, though, is why should the order of these files on the command line matter and does this suggest a compiler or linker bug?

On Monday, 29 October 2012 at 20:56:02 UTC, dsimcha wrote:
> My real question, though, is why should the order of these files on the command line matter and does this suggest a compiler or linker bug?

What exactly are the errors you are getting? My first guess would be templates (maybe the precise GC RTInfo ones?) – determining which template instances to emit into what object files is non-trivial, and DMD is currently known to contain a few related bugs. The fact that the problem also appears when compiling all source files at once is somewhat special, though.

David

The mesasges are below.  The exact messages are probably not useful but I included them since you asked.  I meant to specify, though, that they're all "undefined reference" messages.

Actually, none of these issues occur at all when compilation of the two files is done separately, regardless of what order the object files are passed to DMD for linking:

dmd -c -unittest test.d
dmd -c -unittest emptymain.d
dmd -unittest test.o emptymain.o  # Works
dmd -unittest emptymain.o test.o  # Works

emptymain.o:(.data._D68TypeInfo_S6object26__T16AssociativeArrayTdTdZ16AssociativeArray4Slot6__initZ+0x80): undefined reference to `_D11gctemplates77__T11RTInfoImpl2TS6object26__T16AssociativeArrayTdTdZ16AssociativeArray4SlotZ11RTInfoImpl2yG2m'
emptymain.o:(.data._D73TypeInfo_S6object26__T16AssociativeArrayTdTdZ16AssociativeArray9Hashtable6__initZ+0x80): undefined reference to `_D11gctemplates82__T11RTInfoImpl2TS6object26__T16AssociativeArrayTdTdZ16AssociativeArray9HashtableZ11RTInfoImpl2yG2m'
emptymain.o:(.data._D69TypeInfo_S6object26__T16AssociativeArrayTdTdZ16AssociativeArray5Range6__initZ+0x80): undefined reference to `_D11gctemplates78__T11RTInfoImpl2TS6object26__T16AssociativeArrayTdTdZ16AssociativeArray5RangeZ11RTInfoImpl2yG2m'
emptymain.o:(.data._D149TypeInfo_S6object26__T16AssociativeArrayTdTdZ16AssociativeArray5byKeyMFNdZS6object26__T16AssociativeArrayTdTdZ16AssociativeArray5byKeyM6Result6Result6__initZ+0x80): undefined reference to `_D11gctemplates86__T11RTInfoImpl2TS6object26__T16AssociativeArrayTdTdZ16AssociativeArray5byKeyM6ResultZ11RTInfoImpl2yG2m'
emptymain.o:(.data._D153TypeInfo_S6object26__T16AssociativeArrayTdTdZ16AssociativeArray7byValueMFNdZS6object26__T16AssociativeArrayTdTdZ16AssociativeArray7byValueM6Result6Result6__initZ+0x80): undefined reference to `_D11gctemplates88__T11RTInfoImpl2TS6object26__T16AssociativeArrayTdTdZ16AssociativeArray7byValueM6ResultZ11RTInfoImpl2yG2m'
emptymain.o: In function `_D11gctemplates66__T6bitmapTS6object26__T16AssociativeArrayTdTdZ16AssociativeArrayZ6bitmapFZG2m':
test.d:(.text._D11gctemplates66__T6bitmapTS6object26__T16AssociativeArrayTdTdZ16AssociativeArrayZ6bitmapFZG2m+0x1b): undefined reference to `_D11gctemplates71__T10bitmapImplTS6object26__T16AssociativeArrayTdTdZ16AssociativeArrayZ10bitmapImplFPmZv'

On Monday, 29 October 2012 at 21:08:52 UTC, David Nadlinger wrote:
> On Monday, 29 October 2012 at 20:56:02 UTC, dsimcha wrote:
>> My real question, though, is why should the order of these files on the command line matter and does this suggest a compiler or linker bug?
>
> What exactly are the errors you are getting? My first guess would be templates (maybe the precise GC RTInfo ones?) – determining which template instances to emit into what object files is non-trivial, and DMD is currently known to contain a few related bugs. The fact that the problem also appears when compiling all source files at once is somewhat special, though.
>
> David

On 10/29/2012 10:24 PM, dsimcha wrote:
> The mesasges are below.  The exact messages are probably not useful but
> I included them since you asked.  I meant to specify, though, that
> they're all "undefined reference" messages.
>
> Actually, none of these issues occur at all when compilation of the two
> files is done separately, regardless of what order the object files are
> passed to DMD for linking:
>
> dmd -c -unittest test.d
> dmd -c -unittest emptymain.d
> dmd -unittest test.o emptymain.o  # Works
> dmd -unittest emptymain.o test.o  # Works
>
> emptymain.o:(.data._D68TypeInfo_S6object26__T16AssociativeArrayTdTdZ16AssociativeArray4Slot6__initZ+0x80):
> undefined reference to
> `_D11gctemplates77__T11RTInfoImpl2TS6object26__T16AssociativeArrayTdTdZ16AssociativeArray4SlotZ11RTInfoImpl2yG2m'

I had similar ones aswell. As reported in some other mail, the workaround is to create an alias to the AssociativeArray type.

double[double] aa;
alias AssociativeArray!(double,double) _workaround;

It seems the compiler does not always completely instantiate the class AssociativeArray!(Key,Value) when the type Value[Key] is used. Definitely a compiler bug.

On Monday, 29 October 2012 at 20:56:02 UTC, dsimcha wrote:
> My real question, though, is why should the order of these files on the command line matter and does this suggest a compiler or linker bug?

This would be a bug. Recently this was closed since the example is working.

http://d.puremagic.com/issues/show_bug.cgi?id=4318

Not claiming it to be a wrong choice, just may be relevant to what you are seeing.

On 10/29/2012 9:56 PM, dsimcha wrote:
> I'm running into some inexplicable linker errors when trying to compile
> a project.  I've tried two command lines to compile the project that I
> thought were equivalent except for the names of the output files:
>
> // emptymain.d:
> void main(){}
>
> // test.d:
> unittest {
>      double[double] weights = [1:1.2, 4:2.3];
>      import std.stdio;
>      writeln("PASSED");
> }
>
> dmd -unittest emptymain.d test.d  // Linker errors

This should be fixed with https://github.com/D-Programming-Language/dmd/pull/1313

>
> dmd -unittest test.d emptymain.d  // Works
>
> Additionally, the linker errors only occur under a custom version of
> druntime.  Don't try to reproduce them under the stock version.  (For
> the curious, it's the precise heap scanning fork from
> https://github.com/rainers/druntime/tree/precise_gc2 .  I'm trying to
> get precise heap scanning ready for prime time.)

Did you get further with scrutinizing it?