digitalmars.D.learn - Undefined reference error at linktime with unittests
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__mixin119type8toStringMFZAyaThe same occurs with OPTLINK. Curiously, looking at the incriminated .lib file with an hexadecimal editor reveals something odd:_D5packagename9subpackage9__mixin109type8toStringMFZAyaIs there something i am doing wrong? I couldn't find documentation on what digits mean in mangled function names.(the mangled name in the .lib is mixin109, but the linker is complaining that it cannot find a "mixin119" version of the symbol.)
Dec 10 2020
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 :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?lld-link: error: undefined symbol: _D5packagename9subpackage9__mixin119type8toStringMFZAyaThe same occurs with OPTLINK. Curiously, looking at the incriminated .lib file with an hexadecimal editor reveals something odd:_D5packagename9subpackage9__mixin109type8toStringMFZAyaIs there something i am doing wrong? I couldn't find documentation on what digits mean in mangled function names.(the mangled name in the .lib is mixin109, but the linker is complaining that it cannot find a "mixin119" version of the symbol.)
Dec 10 2020
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.
Dec 10 2020