I have a Visual Studio linker error that popped up recently. I stumbled upon a workaround but it is driving me crazy that I can't figure out why it is happening in the first place. I need to learn how to better diagnose it.
So my question is not about how to fix it, but how to diagnose it better. In short what I'm trying to learn here is how to get the linker (or some other tool) to tell me more info about the problem. So this question is not about this particular enum or how I coded it exactly.
The project is a C++/CLI project I have a managed enum which I wanted to refer to in several other header files. So I tried to put a forward declaration of it in the shared file that I use for all my other forward declarations. That started giving me this error.
1>profileregioncli.obj : error LNK2022: metadata operation failed (801311E4) : Duplicate managed types have different visibilities.
OK, fine. My forward declaration probably looks different to the linker than the definition. But I cannot see how the declarations are different in code. And technically, since the linker doesn't even bother to tell me exactly what type is involved I cannot even be 100% sure it's this enum.
So how do I determine following two things?
Exactly what symbol is mismatching AND
Exactly what is the difference (to the linker) between the two versions.
Obviously the first item I probably know. The second, not at all.
What I have tried so far
I've tried setting linker output to full verbosity but it doesn't tell me anything new. Here is the full linker output
1>------ Build started: Project: Core.Sdk, Configuration: Release x64 ------
1>Generating code
1>0 of 1470 functions ( 0.0%) were compiled, the rest were copied from previous compilation.
1> 0 functions were new in current compilation
1> 0 functions had inline decision re-evaluated but remain unchanged
1>Finished generating code
1>profileregioncli.obj : error LNK2022: metadata operation failed (801311E4) : Duplicate managed types have different visibilities.
1>LINK : fatal error LNK1255: link failed because of metadata errors
1>Done building project "corecli_v16.vcxproj" -- FAILED.
========== Build: 0 succeeded, 1 failed, 10 up-to-date, 0 skipped ==========
ILDasm Microsoft recommends trying to use ILDasm for this error but that doesn't work. When I tried using it from the command line as they described, it tells me I have to use it interactive mode. When I then try to use it in interactive mode and open up the .OBJ file in question, it wants an .EXE or DLL, not an .OBJ
MAP File I tried changing the linker settings to generate a MAP file but it never does. So I'm guessing thats not generated unless linking is successful.
Change Something, anything Sometimes the best way to figure out an obscure linker error is to make a change -- any change -- to force the linker to give you a different error so I tried changing the managed enum type to derive from System:UInt32 (a valid thing to do which I do with some of my other managed enums) just to see if I would get a different error. And I did get it to tell me that there were two different definitions of the enum in question, but not what they were. But aside from that, no extra information
But this still leads me to want to see the two definitions side-by-side. Not in code but as the linker sees them. How do I do that?
Related
When I open a generated solution+project file, I get the following warning for each platform I have in the project file:
path/to/project.vcxproj : warning : Platform '[some_platform, 0]' referenced in the project file 'project' cannot be found.
some_platform is a valid platform in the project, and building, browsing etc all work normally. There is no line number showing where the problem is.
My question is, what does '[some_platform, 0]' really mean?
Coming from Linux, I initially thought the quotes signify that I have [some_platform, 0] literally specified somewhere, which I don't. I don't see ,\s*0 used anywhere in the project file either. How do I decipher that message to be able to find out what it's complaining about?
This is a C++ project if that matters.
Edit: The only places , is even used are inside two messages and an SDK reference. So the [some_platform, 0] is definitely something constructed for the sake of warning, but what does the second part (0) mean?
Resolved: Why VS generates an output like that, I don't know, and who knows what the 0 means. However, it turned out that the platform name is something an SDK would register with VS (or something along those lines) and VS expects it case-sensitive. I had changed ORBIS and Durango to orbis and durango, causing the warning. Fixing the case makes the warning go away (the project was loading and building fine regardless).
I think you might have unmatched solution/project platform and build configurations, resulting in the rare case when visual studio defines or creates new ones: https://msdn.microsoft.com/en-us/library/kkz9kefa.aspx ending in the odd platform names '[some_platform, 0]', '[durango, 0]' and '[orbis, 0]' you have.
Now this is entirely my guess (since I could not find any documents to confirm it). But what that 0 actually means, is the reference to the default build configuration that project should use when you target those individual platforms. For instance, you usually have lines similar to this in the solution (.sln) file:{XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX}.Debug|Mixed Platforms.Build.0 = Debug|Any CPU
In the case above you would use build configuration 0 as the default build configuration when using msbuild solutionname.sln from the console. But since the entire platform was generated for that project, we of-course don't have a default build configuration either, so... lets generate. There is more details and examples of the default build-configuration in this post: Visual Studio solution file - what does the "Build.0" mean?
Now back to what might actually be your real problem. You mentioned SDK references, have you made sure they are pointing to the correct place and any environment variables is properly configured in visual studio? If not, the problem might be related to the warnings mentioned here:
Platform 'Android' referenced in the project file 'san-angeles' cannot be found. The warning message on that question sure looks similar to the warning you have, only you have those oddly generated platform names.
Hope this will help you solve the problem.
When compiling a solution with many projects, if I make a compile time error in a project that many other projects use I'll get a flood of errors in the Error List window of visual studio:
Error 80 Metadata file
'C:\trunk\Projects\Libraries\K2DataBaseClient\bin\x64\Debug\CEPCortex.dll'
could not be found C:\trunk\Projects\TradeAiTeacher\CSC
These errors indicate that a project couldn't be built due to another project not being built. These types of errors cascade and don't really tell me anything useful as I know that its all due to a core project failing to build.
These errors often make it harder to find the actual error in the window.
Is there a way to tell visual studio to suppress this type of output and just show me the compile errors in cases like this to make it easy to find what actual code is broken?
Ideally it once the compile error has been fixed we can toggle this hiding off so I see all errors.
I had originally left this version agnostic but visual-studio 2013 is the version I am most concerned with.
No. The C# compiler categorically refuses to consider one error more "important" than another one. It cannot know how important an error can be, it doesn't know enough about the reason it had to produce the error. A missing reference assembly can produce a lot of errors because type definitions are missing. Of course the compiler cannot know the difference between them being undefined because of the missing assembly reference (ignore) or you mistyping a name (don't ignore).
Interpreting the Error List requires a massively parallel computing machine that's capable of high-speed correlation inference and pattern matching. With practical quantum computing still a distant future, you need to use the one that's readily available to any programmer, the one you have between your ears. Start at the top of the list. And work your way down, feeling less inclined to fix them as you progress down the list.
Never hesitate to rebuild before getting to the end of the list when you fixed a gross error. Like a missing assembly reference.
I've found the best way to work with existing the visual studio behavior is to use the advice in this link: and make the compiler stop after the first compile error.
This seems to get as close to solving my problem as you currently can.
I have a strange build problem in a large solution that includes two Wix projects. Both projects give the following build error:
error LGHT0195: The Windows Installer XML variable 'WixUICostingPopupOptOut' is declared in more than one location.
The file cited for the error is Common.wxs, which I cannot find anywhere. How can I address these errors?
I suspect it has something to do with the experiment held by Bob Arnson to troubleshoot a hard-to-catch issue. In the results of that experiment (part 1 and part 2) Bob advises how to avoid build errors related to the WixUICostingPopupOptOut variable.
Here's a different one from the usual confusion over duplicate symbol errors... :-)
I'm working on some legacy Mac code in an Xcode project that has the same global, "trace", defined in several different source files - for instance:
File1.c: SInt32 trace;
File2.c: Boolean trace;
etc. It's clear the original author meant them to have file-specific scope, but just neglected to prefix any of these lines with "static". That's fine, easy enough to fix.
But I'm kind of shocked the linker isn't flagging these! It looks to me like Xcode's linker (I presume gnu ld) only emits duplicate symbol warnings or errors for functions, that are linked into the code segment - but not global variables that are linked into the data segment. Instead, it silently conflates them, which is causing bugs.
So... how do I convince Xcode to emit link errors for duplicate global variables? Or get this information in some other way that can be a routine part of my build?
Well, I thought I'd answered my own question... :-)
I posted earlier:
So if you're using Xcode with LLVM GCC
4.2, go to the build settings dialog, find the "LLVM GCC 4.2 - Code
Generation" section, and check the "No
Common Blocks" checkbox. This enables
the compiler's "-fno-common" option,
and changes the object file generation
so that ld will choke and emit an
error if you have two globals in
different source files with the same
name.
Unfortunately, that doesn't seem to solve all instances. It seems to work fine if all the globals have the same type.
But the example in the question is taken straight from the code, where a variable named "trace" is defined as a global in two different files with two different types. And that's still not caught by the build system when I check that checkbox.
Is there a "call stack" for compiler errors in Visual Studio 2005 (C++)?
For example, I am using a boost::scoped_ptr as the value in a QHash. This is however causing the following compile error:
1>c:\qt\include\qtcore\../../src/corelib/tools/qhash.h(743) : error C2248: 'boost::scoped_ptr<T>::operator =' : cannot access private member declared in class 'boost::scoped_ptr<T>'
From the build output I know which of my source files is causing the error and the line number in the qhash.h that is causing the error but I am trying to track down the line number in my source file that is generating the error (hence the "call stack" idea).
Please note, I am not looking for the solution to the problem of using a scoped_ptr in a QHash but the problem of tracking down where compile errors are generated. This would also be useful for helping track down weird warnings. More often than not I run into this problem when using templated classes.
Thanks!
Sometimes with strange errors it helps to preprocess the file and look at that output. With VS look for "Generate Preprocessed File" under preprocessor settings (or set the /P switch). This will generate XXX.i from XXX.cpp which may help you figure out the problem.
Make sure you turn off the switch after, with this option turned on it won't generate an obj file.
If you look at the build output, you should see which project and which .cpp file was being compiled when this error occurred.
There is really no notion of "call stack" here, because the compiler processes one source file at a time. You have a compiler error in the header file, so you need to find out which source file including that header was being compiled.
These types of errors can be hard to track down. Usually I end up comment out code and finding the offending line and working from there. After doing it a while you will learn to better read the error messages and understand what tripped up the compiler. As it stands the compilers error messages are just horrible.
In this case it is saying that you have an object of type boost::scoped_ptr<T> that it is trying to copy but the class won't let you (operator= and the copy ctor are both hidden). So you need to look at how the class is used and see why it is trying to copy it. Maybe a scoped_ptr isn't what you need. Maybe you need a shared_ptr?