<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 9 November 2015 at 00:42, Ellery Newcomer via D.gnu <span dir="ltr"><<a href="mailto:d.gnu@puremagic.com" target="_blank">d.gnu@puremagic.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Anybody have any idea what's going on here?<br>
<br>
<a href="https://travis-ci.org/ariovistus/pyd/jobs/90001785" rel="noreferrer" target="_blank">https://travis-ci.org/ariovistus/pyd/jobs/90001785</a><br>
<br>
basically, its running<br>
<br>
gdc -c temp.o (d files..)<br>
<br>
and its giving<br>
<br>
Error: symbol `_D4util11multi_index276__T19MultiIndexContainerTC4core6thread6ThreadTS4util11multi_index127__T9IndexedByS1094util11multi_index89__T6HashedVbi0VAyaa1_61VAyaa21_7479706569642861292e6765744861736828266129VAyaa4_613d3d62ZZ9IndexedByTS4util11multi_index15MallocAllocatorTS4util11multi_index11MutableViewZ19MultiIndexContainer6index08containsMxFC4core6thread6ThreadZb' is already defined<br>
<br>
<br>
Actually, multi_index gives me grief with dmd also, but it doesn't error out:<br>
<br>
/usr/bin/ld: Warning: size of symbol `_D4util11multi_index276__T19MultiIndexContainerTC4core6thread6ThreadTS4util11multi_index127__T9IndexedByS1094util11multi_index89__T6HashedVbi0VAyaa1_61VAyaa21_7479706569642861292e6765744861736828266129VAyaa4_613d3d62ZZ9IndexedByTS4util11multi_index15MallocAllocatorTS4util11multi_index11MutableViewZ19MultiIndexContainer6index08containsMxFC4core6thread6ThreadZb' 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<br>
</blockquote></div><br><p dir="ltr">Normally 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.</p>
<p dir="ltr">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.</p>
<p dir="ltr">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. :-)</p>
<p dir="ltr">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).<br></p>Iain<br></div></div>