www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Command Line Order + Linker Errors

reply "dsimcha" <dsimcha yahoo.com> writes:
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?
Oct 29 2012
next sibling parent reply "David Nadlinger" <see klickverbot.at> writes:
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
Oct 29 2012
parent reply "dsimcha" <dsimcha yahoo.com> writes:
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



emptymain.o:(.data._D68TypeInfo_S6object26__T16AssociativeArrayTdTdZ16AssociativeArray
Slot6__initZ+0x80): 
undefined reference to 
`_D11gctemplates77__T11RTInfoImpl2TS6object26__T16AssociativeArrayTdTdZ16AssociativeArray4SlotZ11RTInfoImpl2yG2m'
emptymain.o:(.data._D73TypeInfo_S6object26__T16AssociativeArrayTdTdZ16AssociativeArray9Hash
able6__initZ+0x80): 
undefined reference to 
`_D11gctemplates82__T11RTInfoImpl2TS6object26__T16AssociativeArrayTdTdZ16AssociativeArray9HashtableZ11RTInfoImpl2yG2m'
emptymain.o:(.data._D69TypeInfo_S6object26__T16AssociativeArrayTdTdZ16AssociativeArray5
ange6__initZ+0x80): 
undefined reference to 
`_D11gctemplates78__T11RTInfoImpl2TS6object26__T16AssociativeArrayTdTdZ16AssociativeArray5RangeZ11RTInfoImpl2yG2m'
emptymain.o:(.data._D149TypeInfo_S6object26__T16AssociativeArrayTdTdZ16AssociativeArray5byKeyMFNdZS6object26__T16AssociativeArrayTdTdZ16AssociativeArray5byKeyM6Result6R
sult6__initZ+0x80): 
undefined reference to 
`_D11gctemplates86__T11RTInfoImpl2TS6object26__T16AssociativeArrayTdTdZ16AssociativeArray5byKeyM6ResultZ11RTInfoImpl2yG2m'
emptymain.o:(.data._D153TypeInfo_S6object26__T16AssociativeArrayTdTdZ16AssociativeArray7byValueMFNdZS6object26__T16AssociativeArrayTdTdZ16AssociativeArray7byValueM6Result6R
sult6__initZ+0x80): 
undefined reference to 
`_D11gctemplates88__T11RTInfoImpl2TS6object26__T16AssociativeArrayTdTdZ16AssociativeArray7byValueM6ResultZ11RTInfoImpl2yG2m'
emptymain.o: In function 
`_D11gctemplates66__T6bitmapTS6object26__T16AssociativeArrayTdTdZ16AssociativeArrayZ6bitmapFZG2m':
test.d:(.text._D11gctemplates66__T6bitmapTS6object26__T16AssociativeArrayTdTdZ16AssociativeArray
6bitmapFZG2m+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
Oct 29 2012
parent Rainer Schuetze <r.sagitario gmx.de> writes:
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



 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.
Oct 29 2012
prev sibling next sibling parent "Jesse Phillips" <Jessekphillips+D gmail.com> writes:
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.
Oct 29 2012
prev sibling parent Rainer Schuetze <r.sagitario gmx.de> writes:
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?
Nov 23 2012