I understand that CLR in its current state is bound to windows OS and provides various services by using Win32 APIs internally.
Since .NET Core is platform independent, this basically implies the same IL code can run on different OS. Is CoreCLR OS specific? Or is CoreCLR code written to take different execution paths depending upon current execution environment/OS ?
From the discussion in coreclr repository:
As far as I am aware the CLR in this repo [coreclr] is identical to the CLR in full .NET and the only differences are in the available API set in corefx.
... but seems like there is at least C++/CLI that is missing...
To answer some of the other questions:
Since .NET Core is platform independent, this basically implies the same IL code can run on different OS
Yes. IL is a custom "language". You can write an interpreter/runtime for it that can run on any platform. This is true for other intermediate representations in other languages too, including java bytecode, llvm ir, python bytecode and so on.
Is CoreCLR OS specific? Or is CoreCLR code written to take different execution paths depending upon current execution environment/OS ?
It's a mix. A particular build of coreclr will only work on one OS, because it has been compiled to use features from that OS (including the OS-specific compiler, linking against the right OS-specific libraries, and running code specific to handle that OS). There is also a Platform Abstraction Layer in CoreCLR so that developers can code against one API - based on the Win32 API - and the PAL layer converts it to the right syscalls on Linux and Mac. As pointed out in a comment by #HansPassant, there's a large number of #ifdefs - both on native side and the managed side of CoreCLR.
Related
I am very new to .Net6 and .Net Core in general. I understand that it is possible to publish a single file executable but I was a bit surprised to see that the executable is over 180MB even though the application is relatively small.
The application is targeted to Windows x64 only and uses Windows Forms. It has a handful of Forms and uses a JSON library and a CLI library.
There are a number of dependencies which were more-or-less added automatically but I don't know if they are all strictly necessary (e.g the ASPNetCore item)
Bearing in mind that I am only targeting Windows and the featureset used is limited, what are the actions I can take to reduce the size of the executable?
Update
I found https://learn.microsoft.com/en-us/dotnet/core/deploying/trimming/trim-self-contained which seems to indicate that 'trimming' of WinForms apps is not (yet) possible.
If you already did not, you may switch deployment mode to Framework-dependent from self-contained in publish profile settings, this will exclude .net runtime and will reduce file size dramatically.
However, excluding .net runtime, diverts from its purpose being single file, as you need to install correct runtime to use application. In my opinion, it is worth to keep single exe file with runtime included.
Use This code into your application.
<_SuppressWinFormsTrimError>true</_SuppressWinFormsTrimError>
I have a existing 64-bit Qt Linux project (C/C++), now I wanted to add additional hardware. Unfortunately the hardware vendor provides a SDK with 32-bit binary-only C .so.
Just including the library leads to an error like this:
/usr/bin/x86_64-linux-gnu-ld: skipping incompatible /home/SDK/lib when searching for -example
/usr/bin/x86_64-linux-gnu-ld: cannot find -example
Is there any way to include this library into my existing project?
I found Mixing 32 and 64-bit Libraries in Linux (gcc), but maybe there are some changes as it's already 7 years old.
Thank you in advance!
The x86 and amd64 ABIs are completely different on Linux, so you can't call 32-bit libraries from 64-bit code directly. That said, you can achieve your objective by creating a separate 32-bit program that proxies calls into the library and exposes them via REST, WSDL, Protobuf, or your favorite way of doing IPCs, and then making those calls from the 64-bit process.
Does anyone know how to publish a .NET Core 3.0 application for ARM64?
I can only select "linux-arm" but no "linux-arm64".
Setting linux-arm in combination with x64 also doesnt work. It says the settings are not compatible.
As stated here it should already be supported: https://github.com/dotnet/core/blob/master/release-notes/3.0/3.0-supported-os.md
The linked article points to the supported OSs, not the list of runtime identifiers. An explanation of an RID and a list of common ones can be found in .NET Core RID Catalog. The full list can be found at the CoreFX repo, in runtime.json. linux-arm64 is included but that's only the base OS. There are a lot of specific identifiers like "debian-arm64", "debian.10-arm64", "rhel-arm64" and "ubuntu-arm64". You'll have to use the RID that corresponds to your distribution.
As the RID catalog explains, a runtime identifier consists of the OS, OS version, architecture and optional extra qualifiers.
[os].[version]-[architecture]-[additional qualifiers]
ubuntu-arm64 is the generic Ubuntu version for ARM64 while ubuntu.19.04-arm64 targets Ubuntu 19.04 specifically.
There's no specific version for Raspbian. If you want to target Raspberry in general, you'll have to use linux-arm. If you want to take advantage of the 4GB RAM model, assuming you already use a 64bit OS you may be able to target linux-arm64.
The linux-arm64 isn't available from the publish profile settings, but if you build it using linux-arm and manually edit your .pubxml file afterwards, it works on the pi just fine. As the link you provided shows, it is supported. It seems it hasn't been added to the tooling yet.
Just publish as usual and then edit .pubxml
Change
<RuntimeIdentifier>linux-arm</RuntimeIdentifier>
to
<RuntimeIdentifier>linux-arm64</RuntimeIdentifier>
Then you can publish on a 64bit Raspberry pi.
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 have a windows screensaver that I want to recompile using the QT libraries, so that I can make available for more platforms.
I am facing problems with the deployment on Vista and XP.
I compile my screensaver statically with MT, and run the dependency checker.
The results are:
MyScreensaver.SCR needs several DLLS, QTCORE4.DLL but no MSVCx80.DLLs.
So far this is fine.
My problem is that QTCORE4.DLL in its turn, does need MSVCP80.DLL and MSVCR80.DLL
As a result my application does not run on Vista systems.
Can I build QTCORE4.DLL to be statically linked the the microsoft libraries (maybe Libcmt.lib ?) so that I do not have any dependencies in the MS CRT DLLs?
Limitations:
I do not want to have the users install the MS VC redistributables. The screensaver is only 1 MB, and it is ridiculus to ask the user to do so many changes in his computer just for a screensaver.
I do not want to use the trick to put the MS CRT dlls in the same application path with the screensaver because screensavers are installed in system32, and I want to install the minimum possible files there.
Finally, I do prefer to produce a monolithic program, rather that a bunch of DLLs
I tried a full static compilation and link of QT, but this is not allowed (if I understood correctly, by the LGPL) and also it is not recommended according to this: http://www.qtsoftware.com/developer/faqs/why-does-a-statically-built-qt-use-the-dynamic-visual-studio-runtime-libraries-do-i-need-to-deploy-those-with-my-application
After trying for solutions in various directions, it seems the most feasible one is to use the QTCore4.dll and QTGui4.dll, but having them linked statically to MSVCRT. In this way, neither my program, nor the QT DLLs will have dependencies on MSVCRT dlls.
Is there a solution to this?
( I am new to QT programming )
Thank you,
Michael
I think they are concerted that parts of your application will be compiled with /MD(d) and parts with /MT(d), but if you control everything (including 3rd party libraries) then its pretty safe to use /MT(d).
You have two options:
Those dependencies are part of Microsoft Visual C++ Runtime Library, you can deploy that library in your installshield and user silently installs it, MSVCRT library not included in Windows by default, you must deploy runtime library in your installshield and copy Qt*.dll DLLs in your application directory.
Use Static Linking of Runtime and Qt main dependencies, with this option you have one executable file, but to static compile of Qt you must have Qt commercial License for commercial use.