How to create x64 version of native console project? - c++

I have a VS2008 solution with several libraries and 4 console apps. All build and run correctly in 32 bit mode. The libraries all build and run in x64 mode in another solution with a C# app and a C++/CLI interface layer.
Now I need to build an x64 flavor of the 4 console apps (functional and unit tests for the libraries).
On the Configuration Manager dialog, the Platform dropdown for these 4 projects offers only Win32 as an option. (x64 is also there for the libraries). The Edit and New options are there but do not seem to offer a way to create an x64 choice.
Presumably VS2008 is disallowing x64 for some reason. Is there some other attribute or option I need to set first?
EDIT: Trying to create a new platform in Configuration Manager fails because there already is an x64 platform. It is available to all the library projects.

If you don't get "x64" in the New Platform combo then the x64 C/C++ compilers are not installed. They are not by default (remarkably) unless you started the VS2008 install with the Custom option and turned the option on. Rerun setup.exe to add them, don't forget to rerun the SP1 setup as well. You can double-check by verifying if the vc\bin\amd64 folder is present in the VS install folder, that's the home of the 64-bit build tools.
Another trap exists when the x64 platform already exists in the solution file, brought in by the managed projects. Be sure to untick the "Create new solution platform" checkbox in the dialog.

It's well supported. You just need to add the platform before it appears in drop-down lists:
Build/Configuration Manager
Active Solution Platform
<New...>
x64
If you are using VS 2008 Express, it will not include x64 support.
EDIT: If the configuration already exists on the solution, but not on the project, use this sequence:
Build/Configuration Manager
Go to the line with the project, column Platform
Drop-Down list, <New...>
x64

Related

“Could not determine which ”make“ command to run. Check the ”make“ step in the build configuration.” Qt creator

I installed Qt Creator 5.10.1 and when I built the project I had a error : "Could not determine which ”make“ command to run. Check the ”make“ step in the build configuration.”.
I have already install Qt on another PC and I saw this question "Could not determine which "make" command to run. Check the "make" step in the build configuration." Qt creator
but in Tools > Options > Build & Run > Kits I have lot of Desktop Qt 5.10.1 so he have 1.
Sorry for my english as I'm french and I 13 so my skill is limited
https://www.dropbox.com/s/lg17a54pdgj9923/screen.png?dl=0
You can see the selected build kit in the Build Kit Selector located at the bottom left of your window (button with the hammer image).
You can also manage any of the Build Kits if you go to Tools > Options > Build & Run.
For any build kit in Qt, you need to have the following components:
Device - You can build your application or your desktop/local computer or a remote computer or device with a different or same kind of processor.
Compiler - Specify the location of a compatible C++ compiler here. Clicking on manage takes you to the Compilers tab where you can add as many compilers as you want. If you are on Windows, you will most likely have a MinGW compiler installed along with Qt at this location - C:\Qt\Tools\MinGW\bin\gcc.exe. You can also select a compiler installed with Visual Studio which will be a MSVC compiler.
Qt Version - The last thing you need to specify is the Qmake builder which is in Qt Version. You will need to select this with the appropriate C++ compiler that you previously selected in this build kit. If you have a MinGW C++ compiler, then specify a path for a MinGw qmake.exe and if it is a MSVC compiler then select a MSVC based qmake.exe. On Windows, all your qmake.exe's will be located at C:\Qt\<Qt-version>\<compiler-version&type>\bin\qmake.exe.
Keep in mind that if you are building the project for a different processor or operating system, you will need an appropriate compiler and Qmake selected.
Once you select these properly (and select that build kit in selector), your project will build properly.

How do you change kits in Qt to target an x86 machine?

I'm currently working on a project in QtCreator. I'm using a library that is x86 based but my current project is targeting an x64 architecture. The obvious solution is to change my project to target an x86 architecture. However, I have no idea how to do this.
I've gone into the appropriate window to configure a new Qt kit. This kit uses the MVCC x86 compiler. I then select this as my default project. After running the new qmake, I attempt to build the project yet get the same error regarding using a 32 bit library in a 64 bit project.
So my question: how do I apply a new kit in Qt? I assume I should be able to click the 'Open Build and Run Kit Selector'and select the kit, however, this just gives me the options of select the x64 kits.
Any idea?
First make sure the kit is added in the Build & Run menu of the Options panel. I think you have performed this step already:
Then go to the Projects tab after you have loaded your project and click on "Add Kit". There you should be able to select your newly added kit:
Finally, you should then be able to select it from the kit selector:

LNK1112: module machine type 'x64' conflicts with target machine type 'X86': Qt creator

I have a application running on linux which I am trying to import on windows. I have set up all the libraries and also made changes to the .pro file. Now when I try to build the project I get this error:
error: LNK1112: module machine type 'x64' conflicts with target machine type 'X86'
I am not sure what is causing this issue.I am using the 32-bit Qt creator. I know there are a couple of links which talk about changing the project properties but all those are related to changing them in Visual Studio. I am using Qt creator and running the project through the Qt UI. So I am not sure what changes have to be done for the project properties through Qt if this has to be resolved.
I had the same problem but my scenario was a little different, I was targeting x64 architecture, and when I changed it to x86 I got this error, it took me some time to figure out that I had to re-build the project to match CPU architectures.
It is obvious that you are compiling for 32 bits target but some of your libraries are 64 bits, which much likely you already know.
Make sure that Qt Creator is using the correct compiler (VC++, MinGW) and machine model (32, 64 bits) for your particular project.
Open your project
File -> Open File or Project... -> ... -> yourproject.pro
Check that Qt Creator auto-detected a compiler that meet the machine model of your libraries.
Tools -> Options -> Build & Run -> Kits
Select (define) the desired Build Kit and other settings for your project.
Select "Projects" from the left panel.
In the upper pane is shown the associated Kits for your project.
You can add more Kits with the "Add Kit v" button.
Hovering the mouse over the associated Kits, a little arrow is shown.
Clicking on it provides operations to apply to the Kit.
You can change or remove the Kit from your project following this little arrow.
Generate a new Makefile based on the new information.
Build -> Run qmake
Rebuild from scratch.
Build -> Rebuild All
I see this post was a while ago but I just ran across the same issue and this may be the solution for someone else that runs into this again. I have a different setup but I got the same error.
My application is running on Windows with Visual Studio 2019 and I needed mine to work properly in both x64 and x86 configurations. I ran into this error when I tried running my project in x86. Here was my solution.
Go to your project's Properties page
Project -> <ProjectName> Properties
Check your Qt Project Settings
Configuration Properties -> Qt Project Settings
Make sure you are pointing to the correct Qt Installation under
General -> Qt Installation
You can check this by checking your Qt Options in the Qt VS Tools Extension for VS. If you don't have it make sure you add it. Mine says "Qt5.13.2" which for me is pointing to the x64 build of Qt but it needs to be pointing to the x86 build.
To change this you need to create a Qt Version that points to the x86 build and change the Qt Installation in Qt Project Settings to point to that one.
Extensions -> Qt VS Tools -> Qt Options
Under Qt Versions tab check the Qt Version that your Property Sheet was pointing to. If it is not correct for your configuration here is where you can create another one.
Press the Add button to "Add New Qt Version"
Build Host: Windows
Version name: <give it a name> (I did "Qt5.13.2_86")
Path: <Path to correct build> (mine was "C:\Qt\Qt5.13.2\5.13.2\msvc2017")
compiler: msvc (automatically sets to this when selecting Windows for the Build Host)
Press OK
Now go back to your Qt Installation under Qt Project Settings in your Configuration Properties in your Project's Property sheet and make it point to the correct Qt Version (Mine was from "5.13.2" -> "5.13.2_86").
This was my solution for a different problem but the same error.
I had the same problem in Qt Creator when I was trying to build for a x64 machine using MSVC 2017. Somehow the linker would always be configured with a x86 target machine and fail.
I noticed that link.exe from a /x86/ directory was being called. Somewhere the path was "stuck". After searching for a while I found several incorrect paths in /MY PROJECTS BUILD DIRECTORY/CMakeCache.txt file. The header of this file indicated that it was generated by CMake: C:/Qt/Tools/CMake_64/bin/cmake.exe.
After replacing all the relevant occurences of 'x86' with 'x64' in that file, and rebuilding the project, the problem disappeared.
I had the same problem, i installed Qt 6.3.1 MSVC2019 but i got multiple linking error related to the architecture "LNK4272: library machine type 'x64' conflicts with target machine type 'x86'".
i solved the problem by changing the compiler of the kit
goto : edit -> preferences -> kits -> goto the MSVC2019 kit -> Compilers (C and C++) in my case they was "Microsoft Visual C++ Compiler 16.11.32630.194 (amd64_x86)" change it to amd64 (or your correct architecture)

Cross-machine DLL creation using VC++

I've created a DLL file using VC++ 2008 with following settings:
Configuration type: Dynamic Library (.dll)
Use of MFC: Use Standard Windows Libraries
Use of ATL: Not using ATL
Common Language Runtime support: Common Language Runtime support (/clr)
The created DLL is working perfectly on my machine (the machine it's created on) but it can't be used on another machine (I tested with 3 machines). For more details, I load this DLL file via JNI (Java Native Interface). On my machine it works, but on others it showing the error of "java.lang.UnsatisfiedLinkError:: The application failed to start because its side-by-side configuration is incorrect...."
My question is:
1. Did I miss any configuration when creating the DLL that can't be worked on multiple environment?
2. Can we created a DLL file that will work on different machines?
Thank you so much!
You need to make sure that the VC++ 2008 Redistributables have been installed on the other machines. To double check this is the problem run Dependency Walker on the other machine and it'll show you what it's looking for:
http://www.dependencywalker.com/
You can find the VC 2008 redist EXE on the microsoft web site:
http://www.microsoft.com/en-us/download/details.aspx?id=29
or the actual DLLs are in the redist folder in the VC 2008 install folder.
Actually you can google for "side-by-side configuration is incorrect" and you will find a lot of hints what the reason could be.
But ... giv this a try first:
In VS, project settings, C/C++, Code Generation: Set "Runtime Library" to "Multi-threaded" (or "Multi-threaded Debug".
(Btw: Do you need Common Language Runtime support?)
Besides what #snowdude says, which is correct, there is another possible problem: if these other PCs don't have VS2008 installed, and you linked to the debug MSVCR* libraries, you're out of luck. Only Release mode binaries can be deployed to user systems without hoop-jumping.

Building ActiveQt (COM) applications with MinGW

I am using Qt 4.6.3 with MinGW on Windows to build Qt apps and now need to add a COM interface to my application. I enabled ActiveQt but was getting post-link errors because I was missing a copy of the MIDL compiler. I downloaded a copy of the latest MS Windows SDK, which includes MIDL, but now MIDL complains it cannot find cl.exe. The only conclusion I can draw is that you can only build ActiveQt applications using the MS compiler, which I would rather avoid. Is a way to get this working with MinGW or am I out of luck?
Using the MS compiler and tools seems to be the only reliable way to get this working.
Well, you can build ActiveQt with MinGW, but using a bunch of COM stuff on top of that may not be possible, because it may or may not be present in MinGW. Some thoughts:
Using any MS SDK tools with MinGW won't work (exception is mingw.org + DXSDK which should work most of the time).
Are you sure you are linking all necessary libraries when compiling? I can't help more if you don't show the exact error messages.
The mingw-w32/w64 project tries to provide a completer "Windows SDK for GCC"; it may contain the libraries/files you are looking for. They provide a x64 and x86 compiler, and pretty good DX support. I have no experience with their COM stuff, but I believe it would be a bit more complete than mingw.org's. You can always contact the developers on the forums or mailing list, they are very helpful.
You could try the Wine implementation of midl, widl. See the Wine wiki page regarding building on Windows.
If you want to give it a quick run, get wine-prgs-0.9.14-mingw.zip and see how it works.
I agree with Rob's second post: it's a very bad thing using mingw for construction of ActiveX objects. Mingw has some bugs regarding ActiveX: https://bugzilla.mozilla.org/show_bug.cgi?id=203299 and also: https://qt.gitorious.org/qt/qt/merge_requests/2710. I kill the whole day to discover it. Use Qt for MSVS instead and all will be ok. ;)
I've solved this problem next way:
Got QtCreator, Msys2 and VS2015 Community installed.
Launching Qt Creator with batch script:
#echo off
call "C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\vcvarsall.bat" x86 8.1
setlocal
set MSYSTEM=MINGW32
set MSYS2_PATH_TYPE=inherit
start "" "C:\msys64\usr\bin\mintty" -i /msys2.ico -e /usr/bin/bash --login -c "/c/Qt/Tools/QtCreator/bin/qtcreator.exe"
exit /b 0
I am launching QtCreator out of Msys2 envioronment because it provides standart Unix tools needed to build 3rd party in my project.
So in theory this is not mandatory to have Msys2 for you.
Please note: do not use WinSDK 10.0 (or above) because it does not have midl.exe in PATH variable.
Doing this way will create PATH environment variable with Qt Creator on top priority (so you will use gcc from Qt installation), Msys2 next (so you can use standard Unix tools) and MSVC and WinSDK 8.1 at last place (so while building you will find midl compiler).
Right now I succeed building dll and passed it to midl form WinSDK, but as for now I am stil trying to register it in system.
I did actually succeed in creating and invoking in-process and out-of-process servers using QT+mingw-w64 today, so here is a write-up.
This was based on the instructions at https://doc.qt.io/qt-5/activeqt-server.html , although they were written for the Windows-native build of QT and using MSVC, so some changes were needed .
Tools installed
MSYS2 updated to latest version (as of 29 Oct 2020).
qtcreator and mingw64/mingw-w64 (64-bit target), installed via MSYS2.
Package mingw64/mingw-w64-x86_64-qt5-static installed (this causes the "Qt5 Static" kits in qtcreator to be enabled).
Visual Studio 2019 Community edition (this provides midl.exe).
https://github.com/lucasg/Dependencies - lucasg Dependencies walker. (Not essential but good for checking your static build worked).
Creating the COM DLL (without a type library yet)
These steps assume prior familiarity with QtCreator+qmake for "normal" executables.
Copy the example project from qtactiveqt/examples/activeqt/simple . I actually couldn't find this anywhere in the MSYS2 installation of QT so I cloned the QT source directly and picked out the example.
In the Kit Management in QtCreator, I selected the qt5-static 64-bit kit. This is to avoid any issues due to DLLs not being found at runtime.
This example is an out-of-process server, so to change to in-process, add to the simple.pro file the lines: TEMPLATE=lib and CONFIG += dll.
Enable static linking in GCC as I describe in this answer: https://stackoverflow.com/a/64583309/1505939
Build the project . This will give a warning that it couldn't read simple_res.o but that can be ignored. This should successfully create the output file simpleax.dll, but then there are some error messages to do with widl not found -- which we will address in the next section.
Writing the type library to the DLL
Other Windows tools (e.g. regsvr32, and any other client who wants to use the DLL) expects to be able to read the type library out of the DLL.
The DLL which was created in the previous steps does not contain a type library. I think this is because none of our toolchain tools know how to create a type library. Instead, we have to use midl.exe supplied with VS Community to generate the type library.
In QtCreator there is a post-build script that's supposed to invoke midl . However that doesn't work in the MSYS2 flavour of QtCreator. It seems it was only written for the native flavour using MSVC as the kit.
So we have to manually do the post-processing, which involves:
In the MSYS2 shell, go to the directory of simpleax.dll.
Run this command: idc simpleax.dll -idl simpleax.idl -version 1.0
Start the "x64 Native Tools Command Prompt" start menu item that came with the VS Community installation.
Navigate to the directory of simpleax.dll
Run the command: midl simpleax.idl /nologo /tlb simpleax.tlb. (Note - just adding midl to the MSYS2 path doesn't work as it can't then find a bunch of other dependencies).
Back in the MSYS2 shell, go idc simpleax.dll -tlb simpleax.tlb.
Note that you only need to do all this if the type library changes (i.e. you make a change to the class definition of your exported COM objects). If just rebuilding the project then only the last step would be needed, which you probably can add as a manual build step in the QtCreator config.
Registration and run test
Congratulations! You should now be able to open an elevated command prompt and run regsvr32 simpleax.dll and have it succeed. (If it doesn't work, run dependencies -chain simpleax.tlb and then at the end it will list any DLL dependencies).
After registration succeeded, I was able to invoke the COM object using VS Community (New C++ Console project, and #import "D:\path\to\simpleax.dll", build, and then it creates a .tlh C++ header file that contains wrappers for the DLL).
Cleaning up the type library
The type library that was created contains a whole bunch of annoying QT guff. I discovered that if you want to create a COM object that's not an ActiveX control, you can use QObject instead of QWidget as the base class. Then you don't get most of the guff that is to do with GUI elements.
Also, taking out the Q_CLASSINFO("EventsID",... line from the COM object's class definition means you don't get all the source/sink guff in the type library (for some reason it decides it has to put all the QT event sinking stuff in there).
After doing that, there is only about one screenful of guff left, including the definition of QPoint and so on, that I would consider to be a bug on the part of QT (since the stuff is not needed). I found I could just remove that from the .idl file prior to invoking midl, and hey presto we have a clean interface that can be published.
The out-of-process server
This also worked for me, identical to the above steps but without step 3 (i.e. leave it as app instead of lib). The procedure for attaching the type library via midl is the same.
Registering the type library via testobject.exe -regserver gives no message to tell you if it succeeded or failed, so another way is to use idc -regserver testobject.exe from elevated MSYS2 prompt, then it will give you a failure message.
I was able to invoke the object via VS Community just the same as for the in-process server.
Further issues still to work out
Figure out how to do this in CMake.
Automate the post-build type library procedure.
Get non-static linking working.
Automate removal of the type library guff (or report a bug)