error: symbol (longsymbol) is already defined

[Iain Buclaw via D.gnu]

On 9 November 2015 at 00:42, Ellery Newcomer via D.gnu <d.gnu at 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__T19MultiIndexContainerTC4core6thread6ThreadTS4util11multi_index127__T9IndexedByS1094util11multi_index89__T6HashedVbi0VAyaa1_61VAyaa21_7479706569642861292e6765744861736828266129VAyaa4_613d3d62ZZ9IndexedByTS4util11multi_index15MallocAllocatorTS4util11multi_index11MutableViewZ19MultiIndexContainer6index08containsMxFC4core6thread6ThreadZb'
> 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_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
>

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.

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/d.gnu/attachments/20151109/68822afa/attachment.html>