Unresolved Externals When Build a VC++ Project with Chained Static Lib Dependencies - by Ari Moradi

Status : 

  Fixed<br /><br />
		This item has been fixed in the current or upcoming version of this product.<br /><br />
		A more detailed explanation for the resolution of this particular item may have been provided in the comments section.

Sign in
to vote
ID 638534 Comments
Status Closed Workarounds
Type Bug Repros 10
Opened 1/26/2011 9:24:00 AM
Access Restriction Public


When we are trying to build exe or dll projects that reference a static lib project that references another static lib project, building the solution will fail to link the exe project with unresolved externals that should be resolved by linking the lowest level dependency.
For example, ExeProject has a project reference on LibA.  LibA has a project reference on LibB.  Linking will fail with missing symbols from LibB.
Rebuilding the solution will succeed.
Sign in to post a comment.
Posted by Alun Jones on 11/6/2012 at 9:41 AM
I have the same issue with VC10, in that I have two projects, one depending on the other, and the "build all" step will frequently work for only a quarter to a half the builds, as it will [apparently randomly] choose to link all dependent projects against the depended-on library in one form - release or debug, x64 or x86.
Felix's solution doesn't work for me - I applied it, and still get the following errors over and over:
LINK : fatal error C1905: Front end and back end not compatible (must target same processor).
LINK : fatal error LNK1257: code generation failed
Posted by OlivierGiroux on 4/5/2011 at 3:26 PM
We're starting to look at migrating NVIDIA's GPU simulation software to VC10 and we're hitting this issue as part of the conversion. We also have large solution files with LIB targets that interdepend and eventually all merge into one or two large binaries. Sometimes the same projects are included in different solutions that define different dependencies (imagine a layered system with a replaceable back-end at compile time) and that looks especially busted right now.

Re-engineering how projects come to depend on each other is a lot of work. Besides being a lot of work, it would require people to re-learn how to manage dependencies after over a decade of pretty consistent behavior.

I would also like to know if you will push this "patch" out to the public in an update.
Posted by fin-petteri on 2/17/2011 at 5:28 AM
Is the fix suggested by Felix a permanent one or will there be some "official" fix later on? I'm asking because from now on every Visual Studio 2010 that is installed will have to be "patched" manually. Someone has to know how to do it and someone has to remember to do it. This is inconvenient and I'd really appreciate a proper "Micorosoft Update" kind of fix.

Best Regards,

Posted by Microsoft on 2/2/2011 at 6:42 PM
Hello Ari Moradi,
Thanks you for discovering this issue. You can workaround this issue by modifying an MSBuild target file. Open %ProgramsFile%\MSBuild\Microsoft.cpp\v4.0\Microsoft.CPPBuild.Targets. Please back up the file before making changes. Look for the line below
<Target Name="GetResolvedLinkLibs" Returns="@(LibFullPath)" DependsOnTargets="$(CommonBuildOnlyTargets)">

Add ResolvedLinkLib to the DependsOnTargets like the line below.

<Target Name="GetResolvedLinkLibs" Returns="@(LibFullPath)" DependsOnTargets="$(CommonBuildOnlyTargets);ResolvedLinkLib">

Let me know if you have difficulties.

Felix Huang
Posted by Microsoft on 1/26/2011 at 6:55 PM
Thanks for your feedback.

We are rerouting this issue to the appropriate group within the Visual Studio Product Team for triage and resolution. These specialized experts will follow-up with your issue.
Posted by Microsoft on 1/26/2011 at 9:59 AM
Thank you for your feedback, we are currently reviewing the issue you have submitted. If this issue is urgent, please contact support directly(http://support.microsoft.com)