2

workerFunc is a function in the unnamed namespace. The MSVC compiler (Version 19.16.27026.1 for x64) was used to generate two object files from the same translation unit, one per machine.

Here are symbol names that compiler has produced for the same source code:

Machine 1:

?workerFunc@?A0x65bd3c1e@@YAXPEAVMyClass@ns1@ns2@@NNNAEAN111AEA_N@Z

Machine 2:

?workerFunc@?A0x50c2f7a6@@YAXPEAVMyClass@ns1@ns2@@NNNAEAN111AEA_N@Z

How to force the compiler to generate same symbol name for different machines for a function in an unnamed namespace?

phuclv
  • 37,963
  • 15
  • 156
  • 475
Roman Byshko
  • 8,591
  • 7
  • 35
  • 57
  • But why? I'm not sure if it's possible - unnamed namespaces shouldn't really have to generate any sort of symbol as they're internally linked. – mukunda Jan 21 '19 at 18:22
  • See this article: [Decorated Names](https://learn.microsoft.com/en-us/cpp/build/reference/decorated-names?view=vs-2017). Try using the utility it mentions, `undname.exe` to see if there is any subtle difference in how the name is undecorated (which may indicate difference in options to the compiler). – Phil Brubaker Jan 22 '19 at 14:16
  • did you try the `/experimental:deterministic` compiler flag? – phuclv Jun 25 '23 at 15:48

1 Answers1

1

I figured out that MSVC determines the symbol name of anonymous namespaces by using the file path of the corresponding source code, i.e. the anonymous namespace is converted to a pseudo-random hash. That said, if your machine A or B have different checkout locations, the resulting object files will contain different symbol names, e.g. in your example A0x65bd3c1e vs A0x50c2f7a6. However, I found a solution for this. Use this undocumented compiler flag to trim the checkout prefix:

/d1trimfile:c:\path\to\checkout\dir\

At least this way the checkout location does not matter anymore.

srohmen
  • 223
  • 1
  • 9