I have the source code for an application which currently builds as 32-bit, and I want to rebuild it to target a 64-bit machine, using Visual Studio 2010 on Windows 7.
I have attempted to do this by going to Project > Properties > configuration Properties > Configuration Manager > Active Solution Platform > and selecting x64, and also Copy settings from Win32. Then I proceed to build the solution. The building process gives a lot of warnings (but this also happens with the 32-bit build, and I think has to do with the fact that the original application was built using VS2005). The build has a single error:
lnk1112 module machine type x86 conflicts with target machine type x64
From what I researched in the internet, this had to do with the 64-bit solution trying to use libraries compiled for a 32-bit machine. I verified this using dumpbin.exe -headers <*.lib file> for all the *.lib files in the source code. All of them say "x86" on the header.
I am fairly confident that I can rebuild the libraries I have source code for, however there are a number of libraries (the dreaded Intel Fortran Libraries) that are also provided and used in the original solution, that were written for 32-bit:
IFCONSOL.lib
LIBIFCORE.lib
LIBIFCOREMT.lib
libirc.lib
libm.lib
Evidently, I do not have the source code for these libraries, and thus I would be unable to obtain "64-bit" versions. I have searched in the internet for "ifconsol.lib 64 bit" and the like, etc., but I have not found nothing meaningful.
My question is then, what are my options? If my solution needs these libraries, how can I obtain similar ones for 64-bit?
This is little more than a "let me google that for you" answer. Using the search term "intel fortran redistributable libraries" will give you lots of hits, the first of which is Redistributable libraries for the Intel® C++ and Visual Fortran Compiler 11.1 for Windows. The libraries are for the 11.1 version of IVF and you may need a different version (it is unclear from your post). These libraries can also be found in any licensed release of the intel compilers.
NOTE: for x64 download the "Intel 64" version of the packages. The "IA-64" version is for Itanium processors, which will not work for you.
Related
When I compile C++ code that uses openmp libs with visual studio, the program is very portable - because it runs in other machines with Windows without problems.
When I compile the C++ code with Eclipse CDT (oxygen and g++ cygwin) for Windows, in general, I need to install the correct runtime libs in the other machines to be able to run the program. I don't find it practical.
Based on this:
1) What is the right way to compile the code including all libs (g++ and openmp) to run in another Windows system?
2) How can do this in Eclipse CDT for Windows?
The problem is not in compiling, but in distributing. Windows and windows toolchains intend to use dynamic linking. Now, if created software are dependent on particular version of runtime, which includes side-by-side build, they can be run only if exactly that build is installed. Several builds of same library version may exist, they are fetched using side-by-side (SxS) mechanics.
On Linux platform this problem is solved through package manager and dependencies. On Windows you have to create an installer, which would contain or have ability to download proper version of libraries. Also installer may do proper changes to OS settings, and register them , for future rollback.
Note, that runtime libraries have debug variants which cannot be distributed and debug build of software must be run on developer system only.
"Portable" apps that appear here and there and can be run without installation, have special status not to be dependant on SxS run-time library. To my knowledge cygwin and mingw32 allowed to create such, the 64bit project of mingw had problems with that. But they are still dependant on particular versions of system .dll and may break or malfunction in case of mismatch.
Even in that case you still need some .dll, from mingw, cygwin, Qt, whatever you use and what is not a part of OS, to place them where program can reach them. Which can be folder comtaining the executable. Static linking became a gimmick of past for desktops, because of code bloat - dynamic library size easily can be dozens of megabytes.
And last: you don't compile anything with Visual Studio or with Eclipse CDT. Both designed to use various compilers, it's juse environments. You have to specify normal;y, what compiler your IDE uses, not what IDE you use to run ot.
We're currently beta testing a Windows application which is built with the latest Visual Studio in C++ and runs on Windows 10. The application dynamically links the VC++ libraries (static linkage is not an option for us).
On 75% of our testers' machines (including all our dev machines), the application works out of the box after installing, but with some others it does not start and fails (presumably) during the process of loading dynamic system libraries (since it does not trigger any kind of exception that would write a minidump as with runtime errors).
Some of these users have had errors about missing runtime dlls which were solved after installing the latest VC++ 2017 redistributable, however the application still would not run.
One user has also checked the library dependencies with the Dependencies tool (https://github.com/lucasg/Dependencies), but his results show nothing strange - there is no obvious difference between the output on a working machine and on his own. There are a few question marks (see screenshot: missing modules as shown in Dependencies) next to some UCRT subdependencies but they are there on working machines as well so I presume they are false positives.
I've also tried to deploy the relevant 40 something UCRT and VC++ dlls as an app local deploy next to the executable but it still wouldn't open on the affected machines (I might have missed some relevant ones, or they were still referenced from the System32 folder)
How would you debug such a problem, providing we cannot reproduce it locally (it works out of the box on two completely new devices with a fresh Windows 10 install and without a build environment) and there is a very little information on what might be going wrong with the library calls?
c000001d is illegal instruction exception code.
Either you are targeting instruction sets like AVX2 or SSE4.1 which the customer CPU doesn't support, or the executable is corrupted (e.g. downloaded in text mode instead of binary mode).
For best possible portability do not specify /arch:AVX or /arch:AVX2 when compiling with VC++. The compiler will then target the base instruction set available on the given architecture (x86 or x86_64 with SSE2).
I need to compile a Portable UpnP library (http://pupnp.sourceforge.net/) for Windows Phone 8.1 or 10.
The library can be compiled in x86 Windows 10 and one person (https://github.com/atraczyk/libupnp) has already created the missing the VS 2015 project files for the library. I used this version and changed the project target to ARM and did several other changes like the following.
I have compiled pthread-win32 (https://github.com/GerHobbelt/pthread-win32) against ARM Processor and it was successful.
I have done some changes and tweaks in the library to make it work.
And, I successfully accomplished to compile pthread-win32, ixml and threadutil projects.
However; The actual project, libupnp, didn't compile because of missing iphlpapi library in Windows Phone environment. I searched online and stackoverflow. And I couldn't find any solution to compile the library without iphlpapi or with a replacement of it. I hope you can guide me on how to compile the library.
TL;DR
Is there any way that I can include iphlpapi library to a Windows Phone 8.1 ARM project to compile the Portable UPnP library for Windows Phone 8.1 ARM based device.
Clarification, I am sticking with this version of the UPnP even though I know there are alternatives. Because, other platforms (Android and iOS) are using this library and there is a common C code that we need to use in all platforms. So, changing the library is not an obvious solution.
I can see an ARM lib of the IPHlpApi.Lib on my system at C:\Program Files (x86)\Windows Kits\8.1\Lib\winv6.3\um\arm\IPHlpApi.Lib. Add this to the linker option of the solution.
I have a MSVC++ 2010 project. All the libraries it's using are cross platform (SDL, OpenGL and FLTK).
Obviously, all I have to do right now is press the debug button and it will compile a nice old .exe for me which can now run on Windows, as long as the DLL files are with it.
I had thought before that if you use cross platform libraries, then the generated .exe would run fine on Ubuntu too. I recently found out that this is not possible, and that the program must be compiled in a special way to run on a certain platform.
Is it possible to compile my project in this magical way with MSVC++ 2010 so that it can run on a Ubuntu computer? If so, then could you please answer my question with some clear steps as to what I should do to compile it this way, keeping in mind I'm new to how all this cross platform stuff works?
EDIT:
If I cannot compile a MSVC++ 2010 project for Ubuntu, is there an IDE I could use that could compile the project for both Windows and Ubuntu?
Thanks.
I suggest you use QT. http://qt.digia.com/
It's probably the best cross platform IDE that can let you compile for Windows, Mac and Linux(ubuntu) systems.
Nope, not possible. While the binary code corresponding to the program can be portable, that's not enough. Executable formats on various file systems are different and not compatible. The executable format is essentially a packaging of the binary data and wrapping it with a header that the target file system understands. In order to produce executables for Ubuntu, the linker must support it. MSVC++ doesn't support Linux formats.
Here's my configuration:
Computer A - Windows 7, MS Visual Studio 2005 patched for Win7 compatibility (8.0.50727.867)
Computer B - Windows XP SP2, MS Visual Studio 2005 installed (8.0.50727.42)
My project has some external dependencies (prebuilt DLLs - either build on A or downloaded from the Internet), a couple of DLLs built from sources and one executable. I am mostly developing on A and all is fine there. At some point I try to build my project on computer B, copying the prebuilt DLLs to the output folder. Everything builds fine, but trying to start my application I get
The application failed to initialize properly (0xc0150002)....
The event log contains two of those:
Dependent Assembly Microsoft.VC80.CRT could not be found and Last Error was The referenced assembly is not installed on your system.
plus the slightly more amusing
Generate Activation Context failed for
some.dll. Reference error message: The
operation completed successfully.
At this point I'm trying my Google-Fu, but in vain - virtually all hits are about running binaries on machines without Visual Studio installed. In my case, however, the executables fail to run on the computer they are built.
Next step was to try dependency walker and it baffled me even more - my DLLs built from sources on the same box cannot find MSVCR80.DLL and MSVCP80.DLL, however the executable seems to be alright in respect to those two DLLs i.e. when I open the executable with dependency walker it shows that the MSVC?80.DLLs can be found, but when I open one of my DLLs it says they cannot. That's where I am completely out of ideas what to do so I'm asking you, dear stackoverflow :)
I admit I'm a bit blurry on the whole side-by-side thing, so general reading on the topic will also be appreciated.
Your question has the answer to your problem: Computer A has VC runtime of version 8.0.50727.867, and Computer B has only version 8.0.50727.42.
You built your libraries on Computer A, and they depend on version 867 of VC runtime. (This can be found in manifest embedded in the libraries.) When you copy them to Computer B, these libraries still require version 867 of the runtime but you have only version 42.
To resolve the VC runtime assembly dependencies, you have to install VC runtime redistributables of version 867 on Computer B. However, I'd advise you to update Visual Studio on Computer B so that you have the same version on both computers. And even better, install Visual Studio 2005 SP1 on both computers and then install this security update to SP1. After installing the latter, your libraries will depend on version 8.0.50727.4053.
it's possible the problem is related with different versions of CRT runtime installed on both machines. is it possible to build all your modules to use statically linked CRT runtime to verify this?
first I'd check that prebuilt dlls by preparing dummy project to load them
I recently had the same type of error when building projects on one machine and then moving them to another machine. The biggest culprit here is likely a debug configuration for one of the binary components. That is, MSVC has the fairly rigid requirement of all DLLs/EXEs being built with the same runtime library, debug or release, otherwise they will not work together.
When I had this happen they also tend to compile just fine, but when you attempt to run them you get that extremely cryptic error message.
You need to ensure that every module you build together uses the same configuration, thus debug or release through the entire build chain. This error also likely comes up with mismatches in other libraries, so make sure your MSVC is the exact same version on the machines where you are building.