www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 18267] New: Linker errors compiling std_data_json dub package

https://issues.dlang.org/show_bug.cgi?id=18267

          Issue ID: 18267
           Summary: Linker errors compiling std_data_json dub package with
                    dmd 2.078.0
           Product: D
           Version: D2
          Hardware: x86_64
                OS: Linux
            Status: NEW
          Severity: major
          Priority: P1
         Component: dmd
          Assignee: nobody puremagic.com
          Reporter: atila.neves gmail.com

Created attachment 1677
  --> https://issues.dlang.org/attachment.cgi?id=1677&action=edit
The module that generates code that can't be linked to

Since this commit:

commit 0fc1c36f4e611d92f903db90ee4d62dd7fdc4067 (HEAD)
Author: somzzz <lucia.mcojocaru gmail.com>
Date:   Mon Oct 16 02:55:59 2017 -0700

    array __equals lowering of dynamic arrays


The following very simple dub project no longer links:

dub.sdl:
name "oops"
dependency "std_data_json" version="~>0.18.2"

source/app.d:
void main() { import stdx.data.json.value; }


$ dub build

error: undefined reference to
'_D15taggedalgebraic__T15TaggedAlgebraicTS4stdx4data4json5value9JSONValue12PayloadUnionZQCn__T8opEqualsTxSQDz__TQDlTQCxZQDtTxQuZQBiMxFKxQBfZb'


Before the aforementioned commit, things work as expected. This is currently
making our builds at work fail due a dependency on std_data_json.

Investigating further, I inlined both std_data_json's value.d module and its
dependency taggedalgebraic, and deleted as much code as possible while still
getting a linker error and ended up with these two files:

app.d:
void main() { import oops; }

oops.d:
<attached>

To reproduce:
% dmd -g -c oops.d
% dmd -g -debug app.d oops.o

The issue goes away if the second line doesn't contain `-debug`. On this
reduced example, what's happening is that the two modules don't agree on the
attribute for opEquals. The linker error is that it can't find 

_D4oops__T15TaggedAlgebraicTSQBb9JSONValue12PayloadUnionZQBv__T8opEqualsTxSQCv__TQCtTQCfZQDbTxQuZQBiMxFKxQBfZb

demangled:

const            bool
oops.TaggedAlgebraic!(oops.JSONValue.PayloadUnion).TaggedAlgebraic.opEquals!(const(oops.TaggedAlgebraic!(oops.JSONValue.PayloadUnion).TaggedAlgebraic),
const(oops.TaggedAlgebraic!(oops.JSONValue.PayloadUnion).TaggedAlgebraic)).opEquals(ref
const(oops.TaggedAlgebraic!(oops.JSONValue.PayloadUnion).TaggedAlgebraic))


oops.o does contain a similar symbol, however:

_D4oops__T15TaggedAlgebraicTSQBb9JSONValue12PayloadUnionZQBv__T8opEqualsTxSQCv__TQCtTQCfZQDbTxQuZQBiMxFNaNfKxQBjZb

demangled:

const pure  safe bool
oops.TaggedAlgebraic!(oops.JSONValue.PayloadUnion).TaggedAlgebraic.opEquals!(const(oops.TaggedAlgebraic!(oops.JSONValue.PayloadUnion).TaggedAlgebraic),
const(oops.TaggedAlgebraic!(oops.JSONValue.PayloadUnion).TaggedAlgebraic)).opEquals(ref
const(oops.TaggedAlgebraic!(oops.JSONValue.PayloadUnion).TaggedAlgebraic))


Notice that the symbol that actually exists is `pure  safe`, whereas the one
being looked for by app.d isn't. It seems then that for some reason the
attribute inference happens differently when compiling each module.

--
Jan 19