fatal error LNK1179

[Hendrik Schober]

Hi,

I am getting
LNK1179: invalid or corrupt file: duplicate COMDAT '<mangled name'
The file compiles fine. What can I do?

Schobi

--
Sp******@gmx.de is never read
I'm Schobi at suespammers dot org

"Sometimes compilers are so much more reasonable than people."
Scott Meyers

[Hendrik Schober]

Hendrik Schober <Sp******@gmx.de> wrote:

Hi,

I am getting
LNK1179: invalid or corrupt file: duplicate COMDAT '<mangled name'
The file compiles fine. What can I do?

Well, re-compiling the file, re-opening
the IDE, and re-booting the machine did
not help. However, commenting out the
changes I made did help and after putting
them back into place one by one it was
gone.
Scary.

Schobi

--
Sp******@gmx.de is never read
I'm Schobi at suespammers dot org

"Sometimes compilers are so much more reasonable than people."
Scott Meyers

[Hendrik Schober]

Hendrik Schober <Sp******@gmx.de> wrote:

Hendrik Schober <Sp******@gmx.de> wrote:

Hi,

I am getting
LNK1179: invalid or corrupt file: duplicate COMDAT '<mangled name'
The file compiles fine. What can I do?

Well, re-compiling the file, re-opening
the IDE, and re-booting the machine did
not help. However, commenting out the
changes I made did help and after putting
them back into place one by one it was
gone.
Scary.

Damn! It is back. I was afraid that
would happen.
What do I do?

Schobi

--
Sp******@gmx.de is never read
I'm Schobi at suespammers dot org

"Sometimes compilers are so much more reasonable than people."
Scott Meyers

[Hendrik Schober]

> [...]

Anyone out there?
Whenever the file needs to get recompiled,
linking fails. Then I comment two lines of
code, build the project, and it links. Then
I go back and uncomment one of the two lines
and rebuild ==> this works. Then I go back
again, uncomment the second line and rebuild
==> it all works now.
Whenever I skip one step, it fails. Whenever
the file is recompiled (due to some header
changing), I have to start all over.
This is driving me mad.

And, of course, if I check this in, the build
might fail, too. So I'm sitting on this file
and don't know what to do!

Schobi

--
Sp******@gmx.de is never read
I'm Schobi at suespammers dot org

"Sometimes compilers are so much more reasonable than people."
Scott Meyers

[Carl Daniel [VC++ MVP]]

Hendrik Schober wrote:

[...]
Anyone out there?

Out here yes - haven't encountered this particular problem, nor heard of it
before, so I'm not coming up with any ideas - sorry.
Whenever the file needs to get recompiled,
linking fails. Then I comment two lines of
code, build the project, and it links. Then
I go back and uncomment one of the two lines
and rebuild ==> this works. Then I go back
again, uncomment the second line and rebuild
==> it all works now.
Whenever I skip one step, it fails. Whenever
the file is recompiled (due to some header
changing), I have to start all over.
This is driving me mad.
May you should try re-writing the code in question using a radically
different style. It seems likely that you're encountering a fairly obscure
bug in which the compiler emits two different bodies for the a single
template instantiation.

And, of course, if I check this in, the build
might fail, too. So I'm sitting on this file
and don't know what to do!

Call Product Support.

-cd

[Hendrik Schober]

Carl Daniel [VC++ MVP] <cp*****************************@mvps.org.nospam > wrote:

[...]
May you should try re-writing the code in question using a radically
different style.
No way. This underlies a fairly important
part of the app. Re-designing this means
another three weeks and we are days from
a deadline.
It seems likely that you're encountering a fairly obscure
bug in which the compiler emits two different bodies for the a single
template instantiation.

I don't understand this.
I suspected that it would emit two equal
bodies for different instances? But you
say, it's the other way around???

And, of course, if I check this in, the build
might fail, too. So I'm sitting on this file
and don't know what to do!

Call Product Support.

It would take days (at least!) to sort
this out through support channels. I
am after an idea what to do today. The
problem is hard to reproduce, since
changing the source file back and forth
makes it (dis-)appear.
This puzzles me the most. Is there any
files (besides PCH's which aren't used
here) where the compiler saves any
state info between compiles???
-cd

Schobi

--
Sp******@gmx.de is never read
I'm Schobi at suespammers dot org

"Sometimes compilers are so much more reasonable than people."
Scott Meyers

[Carl Daniel [VC++ MVP]]

Hendrik Schober wrote:

Carl Daniel [VC++ MVP]
<cp*****************************@mvps.org.nospam > wrote:

[...]
May you should try re-writing the code in question using a radically
different style.
No way. This underlies a fairly important
part of the app. Re-designing this means
another three weeks and we are days from
a deadline.

All the more reason to start taking definitive action. Thrashing on an
obscure tool-chain bug has a low probability of success in any timeframe.

It seems likely that you're encountering a fairly
obscure bug in which the compiler emits two different bodies for the
a single template instantiation.

I don't understand this.
I suspected that it would emit two equal
bodies for different instances? But you
say, it's the other way around???

I think so. I've encountered a bug before that resulted in multiple
instantiations of a template function that were different (but have the same
name). IIUC, the linker matches up like-named COMDATs and discards all but
one - but it does check to verify that they do indeed contain the same
content.

And, of course, if I check this in, the build
might fail, too. So I'm sitting on this file
and don't know what to do!
Call Product Support.

It would take days (at least!) to sort
this out through support channels.

If you never start the process, it'll never happen. IMO it makes sense as a
contingency plan to get things rolling with PSS.
I
am after an idea what to do today. The
problem is hard to reproduce, since
changing the source file back and forth
makes it (dis-)appear.
This puzzles me the most. Is there any
files (besides PCH's which aren't used
here) where the compiler saves any
state info between compiles???

Not that I know of, but there is the .ilk file where the linker saves
information if you have /incremental:yes in your link options. Normally
Release builds don't do incremental links, but that might be something to
look into.

-cd

[Hendrik Schober]

Carl Daniel [VC++ MVP] <cp*****************************@mvps.org.nospam > wrote:

[...]

May you should try re-writing the code in question using a radically
different style.
No way. This underlies a fairly important
part of the app. Re-designing this means
another three weeks and we are days from
a deadline.

All the more reason to start taking definitive action. Thrashing on an
obscure tool-chain bug has a low probability of success in any timeframe.

I'll see if I can narrow it down tonight
as I will have to make more changes to
this file anyway.

What's interesting: It compiled fine at
first try on another machine. As long as
I can somehow make it work by doing what
I did so far, it has to remain low
priority on my todo-list until we have
passed that milestone.
[...] I've encountered a bug before that resulted in multiple
instantiations of a template function that were different (but have the same
name). IIUC, the linker matches up like-named COMDATs and discards all but
one - but it does check to verify that they do indeed contain the same
content.
I see.
[...]

Call Product Support.
It would take days (at least!) to sort
this out through support channels.

If you never start the process, it'll never happen. IMO it makes sense as a
contingency plan to get things rolling with PSS.

Mhmm. After I made it passed that deadline.

I
am after an idea what to do today. The
problem is hard to reproduce, since
changing the source file back and forth
makes it (dis-)appear.
This puzzles me the most. Is there any
files (besides PCH's which aren't used
here) where the compiler saves any
state info between compiles???

Not that I know of, but there is the .ilk file where the linker saves
information if you have /incremental:yes in your link options. Normally
Release builds don't do incremental links, but that might be something to
look into.

I suppose you mean "/INCREMENTAL"?
Thanks, I will try to delete this when I
run into the problem again.
-cd

Schobi

--
Sp******@gmx.de is never read
I'm Schobi at suespammers dot org

"Sometimes compilers are so much more reasonable than people."
Scott Meyers