I have built QuantLib using Visual C++ 2010 Express Edition after converting it from a version built under Visual C++ 2008 Epress Edition. My system is a 64 bit.
I get the following error:
fatal error lnk1112: module machine type 'X86' conflicts with target machine type 'x64'
I am not good at programming and I read a lot of solutions from the web and tried them all but none of them worked for my case. Can you please help me to fix this problem?
It might be a number of things, so I suggest you post to the QuantLib mailing list which is a more appropriate forum for going back and forth and diagnosing problems.
A couple of suggestions you might try in the meantime:
there are unofficial binaries available for a few Python versions. If you don't need to modify the library or the wrappers, try running
pip install QuantLib-Python
and see if that succeeds. If it does, you're done.
It could be that you compiled QuantLib as a 32-bit library and your Python is compiled as 64-bit instead. Check that you have chosen the x64 platform (in VC++2010, besides the menu that lets you choose "Release" or "Debug" configuration, there should be another that lets you choose "Win32" or "x64").
But as I said, it's better to move to the mailing list.
Related
I need to use CEF1 (not CEF3) and I need to do it in VS2017 (rest of the project is in VS2017). Which is a bit of problem, as VS2017 didn't exist at the time of CEF1. I don't even know how to begin. I tried to compile CEF1 in older Visual Studio, but then got linker error for mismatching _MSC_VER
Before I start my answer I need to say that it is highly recommended that you use CEF3 instead. The reasons include:
CEF3 is in active development, currently receiving support, improvements and bug fixes.
CEF3 uses modern versions of Chromium under the hood. E.g. 61 and 62 and the time of writing.
CEF1 is stuck at Chromium 27.
CEF3 can be started in a single process mode, similar to how CEF1 was functioning. This is the biggest reason in my opinion one might want to use it. (Actually I wonder why do you want to use CEF1?)
My answer:
If you can find the branch number you want in this archive (it has binaries for some older CEF1 branches) or if you already have some binaries then you should be able to link them against your VS 2017 project no problem.
If not, then you need to build CEF1 from source. The easiest way in my mind is to satisfy the system requirements for building the release branch 1453 (the last one to support CEF1):
Having VS2010
Windows 8 SDK
You could also try to build CEF1 in VS2017. In this way you are likely to encounter more build errors.
Once the 2nd or 3rd step is complete you can use the output in the VS2017 C++ project.
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.
I have some code here that we used to use to call a Python script from our (very large) application. It worked fine when we used VS2008 (compiler v90), which is what the default version of python27 was compiled with.
In the last year we've upgraded our application to VS2010, and I was looking to update the Python-calling dll, thinking it would be a morning's work. Unfortunately, after wrestling with the linker and missing dlls for ages, most of my colleagues agree that our application and python27.dll are using incompatible versions of Windows CRT.
I thought it would be simple enough to find a version of python27.dll (or indeed another version would be fine) compiled with VS2010 (v100) - but I can't.
Is there a way to call a Python script from an application compiled in VS2010?
An answer may be: Download the python sources - compile a custom python.dll and link against that.
I have the same problem. The solution is indeed to build python from the sources. But there is a big drawback: all extra 3rd party python modules pre-build for Windows that you download from internet will not work! This is because all of those modules will be prebuild with VS 2008 and you get again in trouble with incompatible runtimes. The solution is that all such extra modules needs to be again rebuild from sources, but the task is not easy in all cases. The modules are ususally tested in VS2008 and you get a lot of troubles trying to run them with VS2010. I got this mostly with database connectors for MySQL, MSSQL and others.
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.
We include a 3rd Party lib+DLL that recently causes a lot of trouble on installations. Using dependencywalker, we found that the dll itself refers to two different Versions of
MSVCR80.DLL:
Version 8.0.50727.4053 and
Version 8.0.50727.42
alt text http://img101.imageshack.us/img101/1734/dependencywalk2.jpg
In MOST cases installation makes no problems, even if we distribute none of both versions. But in a number of cases our installation just does not start. We then find messages in the windows system event log from the SideBySide manger: "Version of DLL does not match". In most cases again this problem can be resolved, by installing the .NET framework (although we do not use this). But now we have a case where this does not help.
I know that a solution would be, to install both versions as a shared assembly, but that seems not to be easy, and besides that i would prefer a much simpler solution. Does anybody know a workaround?
Can i somehow use only one version of the Dll?
EDIT:
I now tried cristians advice:
D:\Develop\LEADTOOLS15\patch_maifest>mt.exe -inputresource:ltkrn15u.dll;#1 -out:old.manifest
Microsoft (R) Manifest Tool version 5.2.3790.2075
Copyright (c) Microsoft Corporation 2005.
All rights reserved.
mt.exe : general error c101008c: Failed to read the manifest from the resource of file "ltkrn15u.dll". Ressource not found.
If i view the dlls dependencies with full paths, i see the following:
alt text http://img340.imageshack.us/img340/4122/dependencywalk3.jpg
The lower MSVCR80.DLL is the one withe Version ...42. I dont understand this. Why does MSVCP80.DLL refer to a different Version of MSVCR80.DLL than the one besides it. Is that maybe a problem of the dependencywalker ?
Your best option is to ship the needed DLLs within your applications installer package. Use at least the version that your 3rd party DLL depends on.
Microsoft offers standalone installers for its runtime DLLs (vcredits_*). The latest version for VisualStudio 2005 can be downloaded here. That is also the version that your DLL is linked against. You can silently launch the redistributable package from your installer.
As a manual workaround for already installed systems, simply apply the redist installer on the target machine.
If you choose this method, you don't need to be afraid of version conflicts, as applications depending on an older versions will be redirected to always use the most recent one.
For a better understanding you have look at this MSDN articles.
You have to change / update the manifest resource from the dlls.
mt.exe -inputresource:dll_with_manifest.dll;#1 -out:old.manifest
mt.exe -manifest new.manifest -outputresource:dll_with_manfiest.dll;#1
Sometimes the RT_MANIFEST (type 24) resource type doesn't have the #1 index in resource table, you should use a Resource Viewer (ResourceHacker, or ResEdit) and find out the index number. I have seen cases when the manifest has the #2 index number.