When compiling with unit tests(via «dub test», or adding «dflags "-unittest"»), i'm getting this error at link time :

>lld-link: error: undefined symbol: _D5packagename9subpackage9__mixin119type8toStringMFZAya
The same occurs with OPTLINK.

Curiously, looking at the incriminated .lib file with an hexadecimal editor reveals something odd:
>_D5packagename9subpackage9__mixin109type8toStringMFZAya
>>(the mangled name in the .lib is mixin109, but the linker is complaining that it cannot find a "mixin119" version of the symbol.)

Is there something i am doing wrong? I couldn't find documentation on what digits mean in mangled function names.

On 10.12.20 13:28, z wrote:
> When compiling with unit tests(via «dub test», or adding «dflags "-unittest"»), i'm getting this error at link time :
> 
>> lld-link: error: undefined symbol: _D5packagename9subpackage9__mixin119type8toStringMFZAya
> The same occurs with OPTLINK.
> 
> Curiously, looking at the incriminated .lib file with an hexadecimal editor reveals something odd:
>> _D5packagename9subpackage9__mixin109type8toStringMFZAya
>>> (the mangled name in the .lib is mixin109, but the linker is complaining that it cannot find a "mixin119" version of the symbol.)
> 
> Is there something i am doing wrong? I couldn't find documentation on what digits mean in mangled function names.

This would be easier if you hadn't redacted parts of the mangled name.

It's "mixin10" and "mixin11", not "109" and "119". In mangled names, identifiers are preceded by their lengths. In your example:

* 5 characters: the package name (whatever it actually is),
* 9 characters: subpackage name (whatever it actually is),
* 9 characters: "__mixin10",
* 9 characters: type name (whatever it actually is),
* 8 characters: "toString",
* and "MFZAya" describes the signature of toString.

Name mangling is documented here:
https://dlang.org/spec/abi.html#name_mangling

The meaning of the numbers is described in paragraph 8.

As for why "__mixin11" is referenced but "__mixin10" is being emitted, I have no idea. Maybe you're trying to link against an older object file?

On Thursday, 10 December 2020 at 14:51:51 UTC, ag0aep6g wrote:
>...

Thank you for the explanation on mangles.

The problem was caused by an «unittest{ void main() }» declaration in an import's source file, and for some reason it had both passed compilation and not resulted in the usual "undefined symbol : mainCRTStartup" error when these problems occur. Hence the confusion.