View mode: basic / threaded / horizontal-split · Log in · Help
October 29, 2012
Command Line Order + Linker Errors
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?
October 29, 2012
Re: Command Line Order + Linker Errors
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
October 29, 2012
Re: Command Line Order + Linker Errors
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
October 29, 2012
Re: Command Line Order + Linker Errors
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.
October 29, 2012
Re: Command Line Order + Linker Errors
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.
November 24, 2012
Re: Command Line Order + Linker Errors
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?
Top | Discussion index | About this forum | D home