I searched but didn't see this exact issue answered. We have code (I am building it, not writing it) that fails to compile intermittently due to ambiguous symbol errors. This code produces *.tlb files which evidently contain identical symbols. The developer claims that his code is not the cause of this, but it is the MS build tool. He wants us to reboot when this error occurs. I would think he could change something in the code to alleviate this problem. Can anyone give me some guidance about this? And if it can be fixed in the code, how would it get done, please?
Compiling...
Err_ProjFile: \websvc\AdminWebService\TestNsEndpointInteropClient\TestNsEndpointInteropClient.vcxproj
Err_SrcFile: TestNsEndpointInteropClient.cpp
Err_LineNum: 31 col: 0
Err_Target: ClCompile
Err_Message: C2872: 'EndpointTypeEnum_CenterCord' : ambiguous symbol
Below are the files that reference the tlb files.
websvc
common\lib-proprietary\Aspect.UnifiedIP.Notifications.EndpointClient.tlb
websvc\AdminWebService\AdminWebService.sln
websvc\AdminWebService\TestNsEndpointInteropClient\TestNsEndpointInteropClient.vcxproj
websvc\AdminWebService\TestNsEndpointInteropClient\Aspect.UnifiedIP.Notifications.Common.tlb
websvc\NotificationServer\NotificationServer.sln
websvc\NotificationServer\NsCommon\NsCommon.csproj
Related
problem: when attempting to build completed code VS 2010 returns with compile errors. when "errors" are checked in text environment after a few seconds VS 2010 recognizes that "errors" were in fact not errors at all with no external input. when build is attempted again the entire chain of events restarts.
theories: when i attempt to build VS 2010 it appears to "forget" many of the classes and structs that i have defined. many of the errors are required ';' in between a class or struct declaration and the variable name that it is attached to and the red squiggle that indicates an error appears under the struct / class definition.
Example: myStruct myNamedStruct; //in this case "myStruct" would show a red line underneath for a few seconds when viewed after each build attempt but then VS would decide it is fine after a few seconds.
Trouble Shooting: i have hit the "clean solution" button within the build tab and it consistently returns "Clean: 1 succeeded, 0 failed, 0 skipped" which seams like a positive response to me. i have tried restarting VS, hiding the .suo file (to make intellisense behave), systematically opening each program file forcing VS to properly run it's error diagnostic on each, along with tinkering with turning off and on some of the code environment settings within the tools -> options window.
The rest: i am not naive i am fairly certain my code does have errors within it, but these odd fake errors make it impossible to find and test the real errors. any suggestions would be appreciated.
after significant trouble shooting and research i have come to the conclusion that i was declaring my structs incorrectly (i was not using typedef). i still don't understand why the compiler was only saying they were bad when i tried to build and was ok with these errors the rest of the time.
edit: well after more tinkering the problem still persists. typedef solved the issue for my structs, but my classes are still popping the same "errors".
edit2: after more troubleshooting it was discovered that i had header files indirectly calling themselves through other header files. i guess in effect i was creating endless loops on build. i am still not sure why VS found these errors acceptable in the coding environment but producing errors at build.
All my Vulkan SDK paths are sourced in .profile and give the following results when echoed:
I can enumerate all layers and the application compiles without problems. However, when I run it, I get the following error messages from the debug report callback:
I'm on Ubuntu 17.10 with a GTX 1060 with the 387.42.05 drivers, which support Vulkan 1.1.
Running the application with LD_DEBUG=libs shows 2 errors:
/lib/x86_64-linux-gnu/libpthread.so.0: error: symbol lookup error: undefined symbol: pthread_setname_np, version GLIBC_2.2.5 (fatal)
/home/jesta88/Vulkan/VulkanSDK/1.1.70.1/x86_64/lib/libVkLayer_parameter_validation.so: error: symbol lookup error: undefined symbol: vkNegotiateLoaderLayerInterfaceVersion (fatal)
I have no idea what to make of these errors.
I can't completely explain the first error, although I can reproduce it. It is preceded by
calling init: /usr/lib/x86_64-linux-gnu/libGLX_nvidia.so.0
so I suspect that the nvidia driver is probing for a symbol and fails to find it. Although this is marked as "fatal", it isn't really.
For the second error, I can see that too. I reproduced it by running the build_examples.sh script in the SDK. Then:
cd examples/build
LD_DEBUG=libs ./cube --validate -c 300 2> log
The app runs fine.
To convince myself that the validation layers are loaded and working, I created a validation error by commenting out the call to vkDestroyDescriptorPool (line 2252 in cube.c) and got the expected validation errors.
In this case, I think that the Vulkan loader is trying to look up the vkNegotiateLoaderLayerInterfaceVersion symbol in the driver and failing to find it. This is not a fatal condition either since the export of this symbol by a driver is optional. If the loader does not find the symbol, then it assumes a particular protocol between the loader and the driver. If the symbol does exist, the loader calls it to get additional information about the loader<->ICD interface that the driver supports.
Some more detail can be found in this document.
In short, I don't think that these are actual problems.
Edit: The vkNegotiateLoaderLayerInterfaceVersion issue is really happening when the loader attempts to load a layer, and not the ICD (driver), but the same explanation still applies.
I still can't explain the messages you are getting about not finding the layers.
I suggest setting VK_LOADER_DEBUG=all to get some detailed messages about what the Vulkan loader is doing while it is looking for the layers.
Also, try running the cube demo as I outlined above to see if that app runs correctly.
I'm trying to write an x2 camera driver for a Hamamatsu camera in Visual Studio 2015. The X2 driver template already has windows.h included as an external dependency, but when trying to include a necessary header file, it throws an error that windows.h is not included (along with 80 or so errors of function calls that therefore don't exist). But when I include windows.h, I think it's causing a double include and is throwing this error:
Severity: Error (active)
Code: none
Description: expected an identifier Project :x2camera
File: c:\Program Files (x86)\Windows Kits\10\Include\10.0.10586.0\um\winnt.h
Line: 524
I'm really new to working with Visual Studio projects - how can I include windows.h into the file so it can get the functions and declarations it needs without actually including it and causing a double inclusion? Like I said, it's in the "project dependencies" list, and I think it's being included in another file (but I'm having a hard time finding that).
Or is that not even my problem?
Any help is appreciated.
No idea what the problem was but I somehow managed to get it to compile. I think it needed to be included elsewhere first, then built, then included where it needed to be... which doesn't make sense honestly but maybe it was an error with how the inclusion was functioning.
Either way, my question is now resolved, though the questions that now arise such as "why the heck did this work" are baffling.
I swear I saw a new feature in a recent set of GHC release notes - but now I can find no reference to it. Am I delusional, or does this feature actually exist?
It was to do with loading incomplete modules. As best as I can remember, it allows you to turn off compilation errors due to undefined variables. (Naturally, at run-time this causes an exception to be thrown if you try to actually use the undefined variables for anything.) Does that sound familiar? Or is my mind making this up?
You are looking for a compile time option, vs a language extension, of "defer errors to runtime". That is, compile with -fdefer-type-errors.
I'm having some real difficulties porting a really old Visual Studio 97 C++ project to Visual Studio 2010. Let me begin by first giving a little background on the errors I was getting immediately prior to this new LNK1224 error because they may be related, but I'm not sure.
Prior to my new error I was receiving this error:
error LNK2005: "void __cdecl operator delete(void *)" (??3#YAXPAX#Z) already defined in LIBCMT.lib(delete.obj) nafxcw.lib(afxmem.obj)
Through some digging I found that the reason for this error was because both the MFC and CRT libraries contain definitions for "new" and "delete" so they were colliding. Microsoft provides 2 solutions for this detailed in http://support.microsoft.com/kb/q148652/ . One of them was to make sure that in all your files you always include the MFC headers (afx stuff) first. Well there are about 100 files in this project and I just got tired of trying to find the files that were including resources in the wrong order. So I went with the other solution which is basically forcing libraries to load in a particular order. Basically you have to tell the compiler to ignore a particular library so that you can load it explicitly your self in the order that you choose. In my case, it was nafxcw.lib.
So under Project Properties --> Linker --> Input, I explicitly ignored nafxcw.lib and then explicitly included it at the front of the list.
So after doing this, my LNK2005 errors went away. But they were replaced with one single link error.
error LNK1224: invalid image base 0x287600000
I don't know if I fixed my previous link errors correctly and this new link error is in fact the next thing I have to deal with, or I simply created a more critical link error that is basically stopping the linking process before it gets to my original LNK2005 errors. In either case, there isn't much information I could find on this error. Microsoft doesn't say much in this link about it http://msdn.microsoft.com/en-us/library/3ya3f8wz%28v=vs.80%29.aspx
You specified an invalid base address for the image. Base addresses must be 64KB aligned (the last four hex digits must be zero) and image base must fit within a 32-bit signed or unsigned value.
This isn't all that helpful to me and there seems to be no other clues as to where this problem is coming from. I don't know what the next step is.
OK, so it looks like I have solved my own problem. Here is what I did. I needed to know where the heck this number was coming from so I simply used Notepad++ to do a word search through all the project files looking for "2876" which I got from the error message "LINK : fatal error LNK1224: invalid image base 0x287600000". I found that in the project file (.vcxproj) had the following entry in it:
<BaseAddress>0x287600000</BaseAddress>
So I opened it up and sat there wondering how this number was wrong. I mean I don't even know what this field is for. I didn't even generate this file, M$ made it. Why would the IDE create it's own input file incorrectly? Anyways, as I was trying to google this "BaseAddress" item to figure out what it was, it dawned on me that it looked like there were too many zero's. So I went back and counted and sure enough, this wasn't a 32-bit number, it was a 36-bit number. Deleted one of the zero's, recompiled, and boom it worked. Low and behold, that's kind of what the defintion I looked up, mentioned in the problem statement, hinted at looked up earlier on MSDN but it didn't click.
I don't make a habit to rummage through auto generated files very often so I never questioned that this may be the problem.