Compiling my project against STLPort I get some weird build errors. Weird, because the project runs just fine (and 20-30% faster) though you'd think the build errors would be fatal.
Can anyone enlighten me as to what I'm doing wrong and how to shut these up?
Linking... (Intel C++ Environment)
ipo: error #11017: Cannot open stlport_static.lib
ipo: error #11017: Cannot open libiomp5md
ipo: error #11017: Cannot open libmmt
ipo: error #11017: Cannot open libirc
ipo: error #11017: Cannot open svml_disp
ipo: error #11017: Cannot open libdecimal
ipo: warning #11020: unresolved ?_M_use_facet#locale#stlp_std##QBEPAVfacet#12#ABVid#12##Z
Referenced in ipo_19005obj.obj
[and lots of other unresolved symbols from that last .obj file]
(libiomp5md is from Intel's openmp support, I was using that before switching to stlport, and am still running with openmp now so don't see why that should have changed).
My runtime library (in C++ Code Generation settings) is set to multi-threaded.
Thanks in advance!
EDIT: it seems ipo is inter procedural optimization complaining that it can't open libraries which weren't compiled in the current build. So understandable that these errors aren't fatal, and my output still gets built. Still, any advice appreciated.
IPO is inter procedural optimization complaining that it can't open libraries which weren't compiled in the current build. These errors aren't fatal; the output still gets built but IPO obviously doesn't optimize the libraries it can't optimize.
Related
I've recently moved a large codebase from VS2013 to VS2019 that builds for windows 32 and 64 bit targets.
Debug and release versions compile with numerous warnings, although these are largely the same as existed in the VS2013 build. Most of them are trivial issues that I know to be safe. I'm compiling with the "W3" compiler option.
However when I attempt to compile an "analyze" version of the build, (I include the "/analyze" compiler option) I get many of the following:
error C2220: the following warning is treated as an error
That's to be expected, and some of those errors needed attention. But the first thing that seems strange is that MANY of those "errors" were from the windows SDK libraries - code I'm not exactly prepared to edit.
Then I read the following:
https://learn.microsoft.com/en-us/cpp/build/reference/analyze-code-analysis?view=vs-2019
So I amended "/analyze" to /analyze:WX-", just for the sake of experimenting. This silenced a LOT of the errors, but I still get a number of "Error C2220: the following warning is treated as an error", mostly in 3rd party libraries. I'm happy to fix (or ignore where appropriate) issues that have come up in my own code.
So my question is, how do I suppress this error when it is cropping up in things like the windows SDK and very well-used 3rd party libraries? That fact that this isn't more of an issue makes me suspect I've missed something here. But I currently can't get through a code analysis, which was really not problematic in VS2013.
So, I've been trying to get this small project up and running.
I'm not a C/C++ expert and I think I'm not gonna receive any help with this issue given that the project seems somehow abandoned..
So I'm asking here.
This is what I have done so far:
cloned
created a _out directory
cmake'd from there
Then in VS Community Edition 15 2017 I get the following:
2>LINK : fatal error LNK1104: cannot open file 'dxerr.lib'
Reading around it seems that this is an outdated library not available anymore since Windows SDK 8+.
In the article they terminate saying:
VS 2015/2017: The VS 2015/2017 C Runtime is not compatible with the DXERR.LIB that ships in the legacy DirectX SDK. You will get link errors trying to use it. You can use this module to replace DXERR LIB but will have to rebuild the code that uses it. You can try linking with legacy_stdio_definitions.lib instead, but ideally you'd remove this dependency on the legacy DirectX SDK.
I have no idea which solution applies best to my case and how I can implement it.
Anyway, another thing I tried was removing from dxerr.lib from Additional Dependencies within the SDL2 project Linker properties, like I read here.
But then I got plenty of other errors
So, I'm at a dead end at the moment.
I have msys2 installed on windows10, and I'm recompiling my linux projects to work on windows. So far, there is little problem, everything works fine when I compile using clang or gcc. But I'm unable to link using VS2017.
I can repro the issue with a hello world, basically, it's just this one line of code:
g_print ("Hello World\n");
and I get error
LNK2019: unresolved external symbol g_print referenced
Obviously, I have to tell the linker about glib, but how? I've tried pluging in C:\msys64\mingw64\lib and other likely folders into the linker properties, but I can't seem to find the magic incantation. I just keep getting the same error. What do I need to tell it? Or am I just wasting time on the impossible?
I got a better error message from VSCode - unable to find glib-2.0.lib.
Of course not, no such file exists. So I renamed libglib-2.0.dll.a to glib-2.0.lib, and renamed libintl.dll.a to intl.lib, and now it compiles, links, and runs just fine from VS2017.
This is a terrible solution. In my opinion, Gnome should supply better quality distros.
I'm using Visual Studio 2015, and trying to compile a C++ code in Release mode, x86. My operating system is Windows 10, 64-bit OS and x64-based processor.
After it builds, if I run the .exe file from my laptop, it works perfectly fine. However, if I transfer everything in the Release folder to another computer (Windows 8) - no Visual Studio - along with two DLL files (pthreadVC2.dll and ucrtbased.dll), it gives me error 0xc000007b: the application was unable to start.
I've tried statically linking the libraries, but that didn't help. If I run the Dependency Walker, it says that the file - on my computer - has errors, and gives a log of what's wrong, which I cannot understand:
Error: At least one module has an unresolved import due to a missing
export function in an implicitly dependent module.
Error: Modules with different CPU types were found.
Warning: At least one delay-load dependency module was not found.
I looked around on this website, and apparently it means that 64-bit DLLs are being loaded and I should change that from Path. How do I do that? And why doesn't it work on the other computer, which has the same processor? I installed the Visual C++ Redistributable for Visual Studio 2015, but that did nothing.
Another question: The code uses many external headers. Do I have to export them to the other machine as well? Aren't they compiled as a LIB File?
I'm sorry if I sound clueless, but I rarely write applications using Visual Studio. Thanks for your help!
That error code is an NTSTATUS code, specifically STATUS_INVALID_IMAGE_FORMAT. That usually means that the loader is finding 64 bit modules rather than 32 bit modules. Exactly which modules are the wrong bitness is hard for us to tell. Running the startup under Dependency Walker's profile mode would reveal all.
You do really need to get a clear handle on what dependencies your program has. You have specific dependencies related to your program that go beyond the normal MSVC runtime dependency. Only you can know what your dependencies are. A tool like Dependency Walker can help you understand them, but make sure your understanding is solid. Try not to use trial and error to resolve this.
Compiling libffi with VS11 gives the following linker error
libffi\libffi-3.0.9\ms\Win32\Debug\ffi.dll : fatal error LNK1281: Unable to generate SAFESEH image.
The same project was compiling fine with VS10, but after an auto upgrade with VS2012, it started giving linker error
The Explanation in MSDN is too cryptic and least helpful
I might rebuild with /SAFESEH:NO , but I am unsure of the implication.
Please advise what might go wrong.
The main implication of not having SAFESEH is that your application won't be accepted for the Windows 8 store, or for Windows 8 desktop certification. If that's not an issue for you then feel free to use /SAFESEH:NO.
The documentation says:
The most common reason for the linker not to be able to produce an image is because one or more of the input files (modules) to the linker was not compatible with the safe exception handlers feature. A common reason for a module to not be compatible with safe exception handlers is because it was created with a compiler from a previous version of Visual C++.
Is it possible that the project upgrade to VS2012 changed the setting to /SAFESEH:YES. Perhaps you've never been building with SAFESEH.