Thread overview
Library object name collision
Jan 24, 2023
frame
Jan 24, 2023
frame
Jan 24, 2023
frame
January 24, 2023

When creating a linker library under Windows and having module a/b/foo.d but also d/c/foo.d the linker afterwards is bailing out:

>

.lib(foo.obj) : warning LNK4255: library contain multiple objects of the same name; linking object as if no debug info

And when I did inspect the library it confirmed that the compiler just places the objects twice - contents looks like this:

1.txt
1.types.obj
2.txt
2.types.obj
...
foo.obj
foo_1b34_260.obj
foo.obj
foo_1b44_991.obj
...

Which seems incorrect to me.

Does the compiler use an external command to create the library or does it itself?

Also why have most objects an unique postfix in the name but those files havn't? It's mostly a __ModuleInfoZ or __initZ but not always.

How to deal with this? I could rename the files but can't do that without changing the module name too which sucks.

January 24, 2023
On 24/01/2023 8:59 PM, frame wrote:
> Also why have most objects an unique postfix in the name but those files havn't? It's mostly a `__ModuleInfoZ` or `__initZ` but not always.

Symbols which end in __ModuleInfoZ are symbols that hold per-module information for features like unittests and module constructors.

Symbols which end in __initZ hold information on types, specifically their default initialization state.

So if these two are missing, and they should be there, you have a problem.

Now wrt. LNK4255, I'm not sure why its doing this. You haven't shown how you're building. But if you're doing it manually you may want to try:

  -od=<directory>   write object & library files to directory
  -of=<filename>    name output file to filename
  -op               preserve source path for output files

January 24, 2023

On Tuesday, 24 January 2023 at 08:15:55 UTC, Richard (Rikki) Andrew Cattermole wrote:

>

On 24/01/2023 8:59 PM, frame wrote:

>

Also why have most objects an unique postfix in the name but those files havn't? It's mostly a __ModuleInfoZ or __initZ but not always.

Symbols which end in __ModuleInfoZ are symbols that hold per-module information for features like unittests and module constructors.

Symbols which end in __initZ hold information on types, specifically their default initialization state.

So if these two are missing, and they should be there, you have a problem.

It's a library - if any symbol is missing it will be a problem ;-)

>

Now wrt. LNK4255, I'm not sure why its doing this. You haven't shown how you're building. But if you're doing it manually you may want to try:

-od= write object & library files to directory
-of= name output file to filename
-op preserve source path for output files

Doing it via dub, manually would be the -lib switch I guess.

Thanks! it works well with the -op switch, didn't know I can do with libraries. Only drawback is that every path now stored as absolute path - any way to store only a relative one?

January 24, 2023

On Tuesday, 24 January 2023 at 09:54:01 UTC, frame wrote:

>

Thanks! it works well with the -op switch, didn't know I can do with libraries. Only drawback is that every path now stored as absolute path - any way to store only a relative one?

Ah never mind, it seems only to do this with phobos related debug links