digitalmars.D.bugs - [Issue 18267] New: Linker errors compiling std_data_json dub package
- d-bugmail puremagic.com (63/63) Jan 19 2018 https://issues.dlang.org/show_bug.cgi?id=18267
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 2018