D.gnu - error: symbol (longsymbol) is already defined
- Ellery Newcomer (14/14) Nov 08 2015 Anybody have any idea what's going on here?
- Iain Buclaw via D.gnu (27/41) Nov 09 2015 til11multi_index127__T9IndexedByS1094util11multi_index89__T6HashedVbi0VA...
- Ellery Newcomer (3/6) Nov 09 2015 The warning still appears in dmd 2.069. Do you recommend filing a
- Johannes Pfau (3/12) Nov 11 2015 Yes, please file a bug report.
- Vincent R (5/18) Nov 12 2015 Ok I have posted on Learn forums:
- Ellery Newcomer (3/16) Nov 12 2015 https://issues.dlang.org/show_bug.cgi?id=15324
- Johannes Pfau (7/26) Nov 13 2015 Thanks. I've uploaded a reduced example.
Anybody have any idea what's going on here? https://travis-ci.org/ariovistus/pyd/jobs/90001785 basically, its running gdc -c temp.o (d files..) and its giving Error: symbol `_D4util11multi_index276__T19MultiIndexContainerTC4core6thread6ThreadTS4util11multi_index127__T9IndexedByS1094util11multi_index89__T6HashedVbi0VAyaa1_61VAyaa21_7479706569642861292e6765744861736828266129VAyaa4_613d3d62ZZ9IndexedByTS4util11multi_index15MallocAllocatorTS4util11multi_index11MutableViewZ19MultiIndexContainer6index08containsMxFC4c re6thread6ThreadZb' is already defined Actually, multi_index gives me grief with dmd also, but it doesn't error out: /usr/bin/ld: Warning: size of symbol `_D4util11multi_index276__T19MultiIndexContainerTC4core6thread6ThreadTS4util11multi_index127__T9IndexedByS1094util11multi_index89__T6HashedVbi0VAyaa1_61VAyaa21_7479706569642861292e6765744861736828266129VAyaa4_613d3d62ZZ9IndexedByTS4util11multi_index15MallocAllocatorTS4util11multi_index11MutableViewZ19MultiIndexContainer6index08containsMxFC4c re6thread6ThreadZb' changed from 127 in build/temp.linux-x86_64-3.2/infra/temp.o to 119 in build/temp.linux-x86_64-3.2/infra/temp.o
Nov 08 2015
On 9 November 2015 at 00:42, Ellery Newcomer via D.gnu <d.gnu puremagic.com=wrote:Anybody have any idea what's going on here? https://travis-ci.org/ariovistus/pyd/jobs/90001785 basically, its running gdc -c temp.o (d files..) and its giving Error: symbol `_D4util11multi_index276__T19MultiIndexContainerTC4core6thread6ThreadTS4u=til11multi_index127__T9IndexedByS1094util11multi_index89__T6HashedVbi0VAyaa= 1_61VAyaa21_7479706569642861292e6765744861736828266129VAyaa4_613d3d62ZZ9Ind= exedByTS4util11multi_index15MallocAllocatorTS4util11multi_index11MutableVie= wZ19MultiIndexContainer6index08containsMxFC4core6thread6ThreadZb'is already defined Actually, multi_index gives me grief with dmd also, but it doesn't error out: /usr/bin/ld: Warning: size of symbol `_D4util11multi_index276__T19MultiIndexContainerTC4core6thread6ThreadTS4u=til11multi_index127__T9IndexedByS1094util11multi_index89__T6HashedVbi0VAyaa= 1_61VAyaa21_7479706569642861292e6765744861736828266129VAyaa4_613d3d62ZZ9Ind= exedByTS4util11multi_index15MallocAllocatorTS4util11multi_index11MutableVie= wZ19MultiIndexContainer6index08containsMxFC4core6thread6ThreadZb'changed from 127 in build/temp.linux-x86_64-3.2/infra/temp.o to 119 in build/temp.linux-x86_64-3.2/infra/temp.oNormally it's the frontend requesting to output the same template symbol twice, which doesn't work as well for the assembler than it does for the linker, which discards duplicates. The codegen layer would do this obediently because for some reason the frontend has two or more canonical AST symbols for the same static variable/function - which should be considered a frontend bug. There are reasons why it might be a problem in my end for reasons I decided to snip away in order to save on vertical space. :-) Instead of funneling blame, this could be resolved in the move to 2.067 (maybe just skipping to 2.068). The complete rewrite/architecture of the symbol generation code should in the end have two symbol tables to cache generated locals and statics. Though I say this hesitantly. Using the symbol name as the key to look-up the real symbol is risky, especially with instantiated symbols (I'm positive that there are valid cases where template symbols that clash should be made unique, but I don't recall the exact circumstances at this point in time). Iain
Nov 09 2015
On Monday, 9 November 2015 at 08:53:30 UTC, Iain Buclaw wrote:Instead of funneling blame, this could be resolved in the move to 2.067 (maybe just skipping to 2.068). The completeThe warning still appears in dmd 2.069. Do you recommend filing a bug with dmd?
Nov 09 2015
Am Tue, 10 Nov 2015 05:14:48 +0000 schrieb Ellery Newcomer <ellery-newcomer utulsa.edu>:On Monday, 9 November 2015 at 08:53:30 UTC, Iain Buclaw wrote:Yes, please file a bug report.Instead of funneling blame, this could be resolved in the move to 2.067 (maybe just skipping to 2.068). The completeThe warning still appears in dmd 2.069. Do you recommend filing a bug with dmd?
Nov 11 2015
Vincent R <lol dlang.org> On Wednesday, 11 November 2015 at 13:48:16 UTC, Johannes Pfau wrote:Am Tue, 10 Nov 2015 05:14:48 +0000 schrieb Ellery Newcomer <ellery-newcomer utulsa.edu>:Ok I have posted on Learn forums: http://forum.dlang.org/post/zxrsmgxstoajhotwbujq forum.dlang.org So I suppose it's the same problem ?On Monday, 9 November 2015 at 08:53:30 UTC, Iain Buclaw wrote:Yes, please file a bug report.Instead of funneling blame, this could be resolved in the move to 2.067 (maybe just skipping to 2.068). The completeThe warning still appears in dmd 2.069. Do you recommend filing a bug with dmd?
Nov 12 2015
On Wednesday, 11 November 2015 at 13:48:16 UTC, Johannes Pfau wrote:Am Tue, 10 Nov 2015 05:14:48 +0000 schrieb Ellery Newcomer <ellery-newcomer utulsa.edu>:https://issues.dlang.org/show_bug.cgi?id=15324On Monday, 9 November 2015 at 08:53:30 UTC, Iain Buclaw wrote:Yes, please file a bug report.Instead of funneling blame, this could be resolved in the move to 2.067 (maybe just skipping to 2.068). The completeThe warning still appears in dmd 2.069. Do you recommend filing a bug with dmd?
Nov 12 2015
Am Fri, 13 Nov 2015 03:28:01 +0000 schrieb Ellery Newcomer <ellery-newcomer utulsa.edu>:On Wednesday, 11 November 2015 at 13:48:16 UTC, Johannes Pfau wrote:Thanks. I've uploaded a reduced example. Iain, could you please comment on the bug report about this: The symbol GDC emits is actually marked weak. Does the assembler always complain if a weak symbol is defined twice in one source file or is it just complaining because of the size mismatch?Am Tue, 10 Nov 2015 05:14:48 +0000 schrieb Ellery Newcomer <ellery-newcomer utulsa.edu>:https://issues.dlang.org/show_bug.cgi?id=15324On Monday, 9 November 2015 at 08:53:30 UTC, Iain Buclaw wrote:Yes, please file a bug report.Instead of funneling blame, this could be resolved in the move to 2.067 (maybe just skipping to 2.068). The completeThe warning still appears in dmd 2.069. Do you recommend filing a bug with dmd?
Nov 13 2015