I have a new Macbook Pro (M1) and I need to install multiple versions of dotnet core - my large solution has a mixture of versions, to busy to address that issue right now.
But how to I handle this situation ? (note I have a symlink for the X64 version of dotnet)
I'm not sure if it will work for your specific case, but if you're okay with x64 architecture for all .NET versions, it should work.
Delete usr/local/share/dotnet if you have one.
Download installers with x64 architecture for all .NET versions you need;
You need to figure out which of them will be placed in 64 folder. !! Install them first !! After this inside usr/local/share/dotnet you will have only 64 folder.
Copy all files from usr/local/share/dotnet/64 to usr/local/share/dotnet
Delete usr/local/share/dotnet/64 folder
Install the rest of versions via installer and be sure that thay will be placed in usr/local/share/dotnet NOT in usr/local/share/dotnet/64
I am aware that there are many post about this, but I honestly didn't understood any of it.
So, how do I install a kit for my Qt Creator (open source 5.7)?
I already downloaded and installed MSYS2.... don't know what to do with it.
I already downloaded and installed Qt64 - NG.... no clue what to do next.
I just want to be able to develop in Qt and chose betwen MinGW 32 and MinGW 64.
Thanks in advance!
EDIT: I also checked the wiki page. Most of the commands didn't worked. And I was told that it is outdated.
I know that your question is how do you install a kit for your Qt Creator, but first I think it's needed an introduction (Sorry for your eyes, English it's not my native language)
Introduction
The intention is to use the GCC compiler under Windows, what mean we need MinGW (Minimalist GNU for Windows).
MinGW only works for 32 bits, so we need the 64 bits forks, what means to use the MinGW-w64 or TDM-GCC flavors.
MinGW , GCC compiler for 32bits applications.
MinGW-w64 , GCC compiler for 32 and 64 bits applications.
TDM-GCC , GCC compiler for 32 and 64 bits applications.
With that we can create our applications/programs in Windows. In addition, we have other two different tools:
Qt Framework library, for create GUI's/Interfaces with multi-platform compatibility.
Qt Creator , an C/C++ editor, with additional editing tools for the Qt Framework.
About the binary compatibility chain
When we make an application, we've to follow the chain of libraries compiled with the same compiler version, the same way we've to follow the application binary interface (32 or 64 bits) for those libraries.
This means, if we want to compile an application for 32 and 64 bits with MinGW-w64 5.3, plus the Qt 5.7 Framework, we need:
MinGW-w64 5.3 (with flags 32 bits in the config) and the Qt 5.7 Framwork 32 bits build compiled under MinGW-w64 (MinGW-w64 version 5.3 or lower as long as they maintain binary code compatibility with our compiler).
MinGW-w64 5.3 (with flags 64 bits in the config) and the Qt 5.7 Framwork 64 bits build compiled under MinGW-w64 (MinGW-w64 version 5.3 or lower as long as they maintain binary code compatibility with our compiler).
Now come the weird thing. At Qt official webpage it's only available the 32bits builds for MinGW... I don't know why...
Here is when come the Qt64-NG project, a place where get the Qt Framework 64bits binary packages for MinGW-w64. Unfortunately the project is closed, so only are available until the Qt 5.5 Framework version.
I don't know other place where to get newer 64bits Qt binary packages for MinGW-w64 (Maybe the ones at MSYS2 project? I didn't tried yet). So, if one need it, at this moment must be compiled by oneself (This is for answer your opensource 5.7 comment).
Install and configuration
Now your question. How to install a kit for your Qt Creator. I'm going to answer for 64bit binaries because it's what I use (and latter you just need to do the same thing for 32bits)
For use Qt Creator with MinGW-w64, one just need:
Download Qt Creator and install it. My advice is to download the 4.1 (or upper version) snapshots if one is going to use CMake projects.
Download MinGW-w64 (posix-seh , or your choice flavor) + decompress in one folder.
That's all, with this we can create 32 and 64 bits applications.
By other way, in addition to the above steps, if one want to create applications using the Qt Framework library (a GUI/Interface for our applications), it's needed the binary package, this case 64 bit (The 32bit binary package is available at the Qt official page)
Download Qt64-NG (posix-seh , or your above choose flavor) + decompress in one folder.After that it's needed to execute the qtbinpatcher.exe included in that directory, just a double click.Note: If you change this directory to other path, execute again qtbinpatcher.
Here is where end the installation process. In my case, I have all under the same folder. Example:
D:\Programacion\mingw64_5.3.0rev0\
D:\Programacion\qt64-ng\qt-5.5.0-x64-mingw510r0-seh\
Now you just need to configure QtCreator, in this case:
Tools > Options > C++ , Compilers, Add > MinGW
In name put the compiler version, MinGW-5.3 x64 It's the name that will be shown in Kits
In Compiler path browse for the C++ compiler path, in this case D:\Programacion\mingw64_5.3.0rev0\bin\g++.exeTake note in ABI it's selected to use 64 bits flags in the compiler. That's why we put in name x64. For 32 bits, just duplicate and change the selection.
Tools > Options > C++ , Debuggers, Add
In Path browse to the debugger path, in this case D:\Programacion\mingw64_5.3.0rev0\bin\gdb.exe
In name put the name showed at version, GDB 7.10.1 in this case.It's the name that will be shown in Kits
And, if one want to create 64bits programs using Qt Framework, in addition to the above:
Tools > Options > C++ , Qt versions, Add, and select the qmake.exe placed at the qt64-ng bin directory.
In this case is, D:\Programacion\qt64-ng\qt-5.5.0-x64-mingw510r0-seh\bin\qmake.exe
In name put Qt %{Qt:Version} (qt-5.5.0-x64-mingw510r0-seh)It's the name that will be shown in Kits tab
Now you just need to specify the Kit:
Tools > Options > C++ , Kits, Add
In name MinGW-5.3 x64 (Qt-5.5)
In compiler select MinGW-5.3 x64
In debugger select GDB 7.10.1
In Qt Version select Qt 5.5.0 (qt-5.5.0-x64-mingw510r0-seh)
And in CMake goes the CMake path if one is going to use it (I use it with Ninja ).
Note: For install Ninja just copy ninja.exe to the mingw-w64\bin directory, and at the Kit, in Cmake generator push change to generator->ninja , and Extra generator->CodeBlocks. Ninja launch several make commands at same time, what decreases compilation times.
Long text for 1 minute of configuration. The Kit is what we select for compile the project, and one can have as many Kits as one wish (CompilerA x32 + Qt5.x , CompilerB x64 + Qt5.x , CompilerX x64 + Qt4.8, etc, etc).
Now, before to finish, an important thing. After we create a project (and the project it's open), at the Projects selector (Ctrl+5) we've to take care of the Build Environment variables.
Those are the variables that are going to be added at the command who launch our Runs/Builds for testing and debug.
In PATH it's needed to put the paths to MinGW-w64 and to Qt64-NG. And under my humble opinion, I recommend to put it in that order because of dll's. Following our example:
PATH D:\Programacion\mingw64_5.3.0rev0\bin;D:\Programacion\qt64-ng\qt-5.5.0-x64-mingw510r0-seh\bin;the_other_paths
At QtCreator snapshots branch I don't need to check it, it's done automatically
Most of the C/C++ editors works that way. To install editor, specify compiler&debugger path, and specify Build Environment variables for launch from the editor (overriding those environment variable that we've in Windows).
Note: I recommend to compile Qt Creator with 64 bits, due as happen with the Framework, for Windows it's only available in 32 bit at the official Qt website
Alternative way
By other side, we have:
MSYS2 , a Linux like tools environment.
There is all the same, just we download/install the packages with the pacman command, and are available the 32 and 64 bit versions. Those applications need to be launched from MSYS2 shell. It's not a binary compatibility thing but a paths matter.
The libraries available at MSYS2 project can be used in the first tool chain I described (due are build under MinGW-w64 also).
EDIT: Corrected namings, the last explanation, and added Ninja's url and installation note.
You should decide if you are going to use the MSYS2 ecosystem or not. If you want to use MSYS2, you should uninstall the Qt software that you downloaded separately to avoid confusion. For the rest of this answer, I'll assume you are using MSYS2.
You can install these MSYS2 packages using pacman:
mingw-w64-i686-qt
mingw-w64-i686-qt-creator
mingw-w64-x86_64-qt
mingw-w64-x86_64-qt-creator
Then open up a MinGW-w64 32-bit or 64-bit shell using the appropriate shortcut in your Start Menu, and run "qtcreator" at the command line.
You can also use other build systems to build your software. I have used CMake successfully for building Qt applications in MSYS2, instead of Qt Creator.
Directly launching from explorer will also work, unless you need to use qtcreator's Autotools plugin in which case launching it from an msys2 shell is necessary (so that various environment variables are set correctly).
From this documentation it is not clear whether it is possible to build an executable that uses shared libraries once Qt (> 5.0) has been rebuilt in static mode.
I need to build both executables that use shared libraries and executables which are usable without them. Do I need to have two separate installations of Qt for that, or is it possible to use a flag to specify the desired behaviour?
Is it possible to configure QtCreator for this purpose?
Platform: Windows 7, MinGW32/GCC 4.8
I am currently using Qt on Windows 7 in the (almost) exact configuration as you described. Only thing is that you will have to create 2 different compilation Kits for each purpose.
For static compile I have mingw32 compiler and for shared compile I have MSVC2010 32 bit SDK.
EDIT:
Yes I have a statically built version of Qt 4.8.4 (qmake) and I have a Qt 5.0.0 MSVC2010 32bit (SDK) (normally built). I have created 2 separate 'Kits' using these two versions and having different compilers as mentioned. You need to include the following line to the .pro file. It gets ignored during shared build.
#CONFIG += staticlib
We using Gallio for test execution. All projects under test and all test projects are compiled as 32bit Version. The Buildserver is Win2008 R2 64bit.
Gallio is installed as 32bit version.
Gallio is startet through Sonar. As coverageTool we use OpenCover.
As the title says the BadImageFormat Exception is the Problem. Then Trying to run, the .Net\Framework64\ folder is used. But all targets are set to 32bit architecture.
After two days of testing and researching I tryed different Gallio Versions:
32bit installer
64bit installer
Gallio Bundle Zip
I tried to rename the Gallio.Host.x86.exe to Gallio.Host.exe
I tried to force Gallio to run in 32bit mode via CorFlags Galio.Echo.exe /32BIT+ /FORCE
(Using /FORCE will invalidate the signature of this image and will require the assambly to be resigned)
Has anybody a Idea what I'am doing wrong?
Make sure you're running Sonar v3.0 (or greater), as most 64-bit issues were resolved with that release. I would also suggest moving to PartCover as your coverage tool. (Edit: PartCover is the way to go now)
Then Trying to run, the .Net\Framework64\ folder is used
What do you mean by "used"? Even if every executable is correctly marked and run as a 32-bit process, if one of them tries to load a binary in the Framework64 folder (all 64-bit binaries) a BadImageFormatException would be expected.
Try renaming both "Gallio.Host.Elevated.x86.exe", "Gallio.Host.x86.exe" to "Gallio.Host.Elevated.exe", "Gallio.Host.exe". That worked for me - running nunit tests (x86) with gallio
We have a project that compiles to a 32-bit COM DLL and to a 64-bit COM DLL (the same one from my earlier question). When I register both on my Windows 7 machine, both register successfully. When I register both on a Windows Server 2003 machine, both register successfully.
But when I try to register the DLLs on a Windows Server 2008 R2 standard SP1 machine, the 64-bit DLL registers successfully, but the 32-bit DLL fails with the message (sic):
The module ""%1"" may not compatible with the version of Windows that you're running.
Check if the module is compatible with an x86 (32-bit) or x64 (64-bit) version of regsvr32.exe.
I don't think a 32-bit DLL can be compatible with WS2003 and Win7 but not WS2008. That makes no sense.
What might be happening?
The version of Regsvr32.exe must match the 32-/64-bitness of the dll you're trying to register. The 64-bit regsvr32 cannot load a 32-bit dll, and vice versa.
You may need explicitly call the 32-bit version of regsrv32 located in %systemroot%\SysWoW64\regsvr32.exe.
From http://support.microsoft.com/kb/249873
Regsvr32.exe is included with Microsoft Internet Explorer 3.0 or later versions, Windows 95 OEM Service Release 2 (OSR2) or later versions, and Windows NT 4.0 Service Pack 5 (SP5) or later versions. Regsvr32.exe is installed in the System (Windows Me/Windows 98/Windows 95) or System32 (Windows NT/Windows XP/Windows Vista/Windows 7) folder.
Note On a 64-bit version of a Windows operating system, there are two versions of the Regsv32.exe file:
The 64-bit version is %systemroot%\System32\regsvr32.exe.
The 32-bit version is %systemroot%\SysWoW64\regsvr32.exe.
Regsvr32.exe usage
RegSvr32.exe has the following command-line options:
Regsvr32 [/u] [/n] [/i[:cmdline]] dllname
/u - Unregister server
/i - Call DllInstall passing it an optional [cmdline]; when used with /u calls dll uninstall
/n - do not call DllRegisterServer; this option must be used with /i
/s – Silent; display no message boxes (added with Windows XP and Windows Vista)
When you use Regsvr32.exe, it attempts to load the component and call its DLLSelfRegister function. If this attempt is successful, Regsvr32.exe displays a dialog box that indicates success. If the attempt is unsuccessful, Regsvr32.exe returns an error message. This may include a Win32 error code. For more information, click the following article number to view the article in the Microsoft Knowledge Base:
193625 WinInet error codes (12001 through 12156)
This isn't likely to be the problem in your case, but might be useful for others who find this question by searching on the same error message:
I had a similar problem: a DLL that wouldn't register with either the 32-bit or 64-bit version of RegSvr32. I loaded the DLL the Dependency Walker (depends.exe, http://www.dependencywalker.com/) and got a much more useful message:
Error: At least one file was not a 32-bit or 64-bit Windows module.
Scanning the CPU column in the Module List identified the offending module. (In my case, it said "No DOS or PE signature found. This file is not a valid 32-bit or 64-bit Windows module.")
Moral: The Dependency Walker might give you a more useful error message than RegSvr32.exe.
I got it registered by moving the dll to the c:\windows\syswow64\ directory (it wouldn't work in the system32 directory) and then explicitly calling syswow64\regsvr32, eg
c:\windows\syswow64\regsvr32 yourdll.dll
btw it wouldn't work when calling c:\windows\syswow64\regsvr32 c:\windows\syswow64\yourdll.dll
Use Process Monitor from SysInternals.
1. Filter by "Process Name" = regsvr32.exe.
2. Try to register your DLL file from the correct version of regsvr32.exe (the 32-bit version is in the SysWow64 folder)
3. Process Monitor will trace EVERYTHING that is happening on your computer.
4. First start your analysis by eliminating the registry events (for now):
5. You may be able to see which DLL file is found and not found.
Here a (very) partial screenshot of regsvr32.exe of Threed32.ocx where we can see some of the required DLL files:
6. Your work is just starting. From now.
I have the same problem, but I resolve it with commands
CD \windows\syswow64
regsvr32 c:\filename. dll
Running the command prompt as administrator fixed my issue.