Visual studio 2015/2017/2019/2022 all come with (somewhat hidden) compiler for 32-bit ARM processors. The 64-bit ARM Windows also comes with support for running 32-bit applications. However, after I built some C++ applications using that 32-bit compiler I find myself unable to actually run it because build rules for most software include /MD compile flag which links the exe/dll-s against the dynamic VS runtime in a few dll-s (vcruntime140.dll, etc.). My arm system is missing that runtime (at least the arm version) and I cannot find it anywhere. All the publicly available runtime downloads include only x86, x64 and arm64.
What am I missing? Building modern software with the runtime linked-in is inefficient and often will not work correctly due to sharing runtime-specific structures across library boundaries. But the dynamic runtimes are nowhere to be found. Is 32-bit ARM considered deprecated or only useful for simple single-binary embedded applications? Or is there something about arm platform which makes linked-in runtimes work for applications spanning multiple binaries? Are the arm runtime installers available in some dark corner?
Related
I'm trying to build a simple application with CUDA and I've been trying for hours on end and I just can't make it work on windows. nvcc absolutely refuses to compile without Visual Studio's compiler which doesn't support things I need. I tried building using nvcc with clang but It just asks me to use Visual Studio's compiler. I've also tried using clang directly since it now supports CUDA but I receive this error:
clang++.exe: error: Unsupported CUDA gpu architecture: compute_52
This makes no sense to me because I have the CUDA toolkit version 7.5 and my graphics card is a GTX 970 (two of them). I have googled this extensively and everywhere I come across the error the person always has is their CUDA toolkit is < 7.5. I'm on the brink of tears right now trying to get something as simple as VLA to work on this CUDA application and I just can't achieve it...
The CUDA windows toolchain requires the Visual Studio C++ compiler. You cannot use anything else on that platform. If the VS compiler doesn't support the language features you need within CUDA host code, you have no choice but to change platforms, or your expectations.
You can still potentially compile non-CUDA host code using another compiler and then link that code using NVCC and the VS toolchain.
Try to use clang-cl, --cubin=clang-cl.exe
It may be worth to work on a Linux VM or WSL2 within windows. As per the CUDA docs.
To compile new CUDA applications, a CUDA Toolkit for Linux x86 is
needed. CUDA Toolkit support for WSL is still in preview stage as
developer tools such as profilers are not available yet. However, CUDA
application development is fully supported in the WSL2 environment, as
a result, users should be able to compile new CUDA Linux applications
with the latest CUDA Toolkit for x86 Linux.
https://docs.nvidia.com/cuda/wsl-user-guide/index.html#:~:text=However%2C%20CUDA%20application%20development%20is,becomes%20available%20within%20WSL%202.
I've downloaded the MSVC ABI version of Rust 1.7.0 and followed the guessing game section from the docs.
I notice that the builds use the native toolchain (Visual Studio 2015 Update 2 in my case) and therefore generate native PDBs (debugging symbols) consumable by native debuggers, such as WinDBG, CDB or the Visual Studio debugger. I can easily set breakpoints, step into standard library source and so on.
What I cannot do is to inspect variable values. Regardless of the debugger used, the 'Locals' display is empty.
From what I can gather, the Visual Rust/RustDT IDEs display locals when using GDB or LLDB as a backend, not the native Windows debugging engine. I'm not entirely sure if I can use these to debug Rust programs compiled for MSVC ABI (with PDBs and so on).
If I want to have the necessary debugging experience, is my only option to switch to the GNU ABI? Barring that, is there an easy way to map to Rust symbols (variable values) from the raw debugging tools (registers, memory map)?
Features don't exist until they're implemented. Rust is built upon LLVM and full PDB support has only recently been considered for LLVM. For now LLVM has only a limited PDB support, with the limitations best described on the Clang project's MSVC compatibility page. In my opinion, it's best to wait until the support is there, although for other programming languages interesting workarounds have been implemented.
I have a 32-bit object file o.obj and want to use it in a project that uses a 64-bit library l.lib.
To make the .lib happy, the Visual Studio configuration needs to be set to x64. However, the linker then throws an error of error LNK1112: module machine type 'X86' conflicts with target machine type 'x64'.
I went through Visual Studio's linker options, but nothing jumped out. Is there a way to resolve this error?
I was under the impression that any 32-bit code is also compatible with 64-bit systems, modulo libraries.
x86 executables (that is, object code compiled for 32-bit x86 processors) can be executed on x64 machines running 64-bit operating systems, through a special compatibility mode supported jointly by the processor and the operating system. This is feasible because the x86 instruction set is a subset of the x64 instruction set.
However, many elements of the ABI differ between x86 and x64 code, notably calling conventions and pointer size. The calling convention needs to match between the calling code and the called code, or things will screw up. Thus, there is no straightforward way to call 64-bit code from 32-bit code, or vice versa.
So my boss asked me to test code on VS2012(x86) and VS2012(x64) redistributable package,
but when I look at the configuration manager>platforms... the only options on testing VS2012 are x64 and Win32.
So my question is when I build my code with Win32, is that the same as building for x86?
Yes. Win32 was the name used in old versions of VS, before 64-bit processors where available. Back when it could also build 16-bit DOS and Windows 3.x programs, Win32 distinguished targeting Windows 9x and Windows NT.
Picking "x86" would not have been a good choice back then, those 16-bit programs also ran on a x86 processor. It only recently became synonymous with "32-bits". They just never changed it.
So my question is when I build my code with Win32, is that the same as building for on x86?
Yes. In this context x86 is synonymous with Win32.
I have a problem related to this question. Two players:
C# application
Mixed assembly used by 1)
The application has to support anything from Windows XP (32bit) to Windows 7 (32 & 64bit). The assembly is complicated in different ways. It contains managed C++/CLI code and some native C++ classes dancing with native DirectX. It also is linked to a few 32bit native dll's w/o source access (containing C++ classes with import libraries).
Things are working well in 32bit environments (XP and 7 tested) including the 32bit subsystem on Windows 7. Havoc happens, as soon as "Any CPU" is used on 64bit systems in order to build the complete solution. The 32bit assembly is unusable than - but seemingly only in debug mode ("cannot load, wrong format" etc.). It seems to work in release. A 64bit assembly build is prevented by the implicit dependencies to the mentioned 32bit third-party dll's.
Is there any way to provide a real native 64bit application able to use the assembly?
Requirement for the assembly isn't that strict. It could be both - 32 or 64bit - but as said above, should be be usable from the application one way or the other.
You are running into a rock hard limitation in the 64-bit version of Windows, a 64-bit process cannot execute any 32-bit machine code in-process. You certainly have a dependency on machine code when you use C++/CLI and work with DirectX. Although it doesn't sound like you could not execute in 64-bit mode, both C++/CLI and DirectX can be compiled/are available in 64-bit.
This then boils down to a build and deployment issue. You have to build the C++/CLI project(s) in 64-bit mode and deploy only 64-bit components on a 64-bit operating system. The main EXE must be built to AnyCPU. Similarly, on a 32-bit operating system you must build and deploy only the 32-bit compiled version. You solve the build issue by adding the x64 configuration to the solution so you build the 32-bit and 64-bit version separately. You solve the deployment issue by creating two installers.
Since you have to support a 32-bit operating system anyway, the simple solution is to change the Target platform setting on your EXE project to x86. Now everything always runs in 32-bit mode and you don't have to bother with the build and deployment headaches. The only thing you miss out on is the larger virtual memory address space that's available in the 64-bit version.
Forget about the C++/CLI project for a minute.
You have third-party 32-bit DLLs. These CANNOT load in a 64-bit process. So your main application will have to be 32-bit. This restriction has nothing to do with the C++/CLI middleman.
The only way you can make use of these DLLs from a 64-bit application is to load them in a separate (32-bit) process and marshal data back and forth.