Grpc tools has 2 folders - windows_x64, windows_x86. The exe's (grpc_csharp_plugin, protoc) are of different size but the stub files created by them are the same.
Can I conclude that the folders for x64, x86 denote the platform on which the exe's are run and NOT the targeted platform's for the stub files?
Yes, the codegen does not vary by platform. There is only a different stub generation per language. To help users run the code generator (which is C++) there are pre-built binaries for a variety of common platforms. All platforms generate the same code.
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 got an app, that is ready to release. On windows, I simply type 'windeployqt.exe MyApp.exe' inside 'release' folder of app build in special qt cmd. I'm trying to do the same on kali linux (I dont have time to install other deb based distro). I'm searching for solution for three hours, and I cant find anything good. So, how to make application executable on other linux computer without Qt Creator installed?
There are many ways to deploy Qt applications on Linux. AppImage created with the help of linuxdeployqt or linuxdeploy-plugin-qt is one option, perhaps even the simplest one but it has its drawbacks. From my personal experience I can think of two:
Your app won't generally be able to use native icon/font/other themes.
Sometimes your AppImages might occasionally cease to work due to some unexpected system update which would, for example, break the binary compatibility of OpenSSL libraries.
Other packaging options for Linux include:
Linking the application with static version of Qt. It is the
approach used e.g. by Telegram. The instructions can be found
here.
Beware, however, that using this approach for commercial closed
source applications generally requires commercial Qt license.
Probably it is possible to get away with LGPL but it would be very
cumbersome: you'd have to provide customers with compiled object
files so that they can replace them and re-link the app. Also beware
of the fact that if the application you intend to create is going to
be an open source one, the maintainers of Linux distributions would
generally not agree to distribute statically linked applications -
that violates the basic rules for many distros according to which
applications should not bundle their dependencies but instead should
use the system provided libraries. It is important from e.g.
security perspective - if some security threat is found in Qt in
future, it can be fixed within a Qt library itself and all
applications using that library would then also be secure -
something not that easily achievable with application built with
static version of Qt.
Creating native packages for target systems - i.e. deb packages for
Debian/Ubuntu systems and their derivatives, rpms for Fedora,
OpenSUSE and other rpm-based distros,
PKGBUILD for Arch
Linux and various other kinds of packages for various other distros,
hundreds of them. The advantage is good integration with the rest of the system: native themes etc. Also you get all the advantages of the security fixes for shared libraries.
Using flatpak or snap packages - these are modern app packaging formats developed by RedHat and Canonical respectively with the goal to simplify the management of app's dependencies.
Using the generic approach using shared libraries - with this approach you'd need to package your app as an archive containing a directory containing you app and all its dependencies in the form of shared libraries - something similar to the approach of deployment on Windows where you put the dlls alongside the app.
I would recommend trying an AppImage first and then creating native packages for target distros.
how do you create standalone(just one exe) application with qt?
You don't. Assuming you mean distributed to any machine without the Qt libraries. You can, however, easily deploy applications (in Windows) with all needed libraries using the windeployqt tool.
Whats the best way to deploy a QT app? I've read the documentation hosted at trolltech but is it better to link with a static library or the dynamic libraries and have the user install the framework? I don't really want anyone using my app to have to download a 160mb framework just to run a simple gui frontend.
On OS X it's a good way to do a dynamic build and post-process the resulting ".app" with the macdeployqt tool which comes with Qt starting with 4.5.
This will copy the Qt frameworks used by your application into the application bundle, which results in a larger package than building a static version of your application.
Here is what you can do to make sure you get the smallest file size possibly in a dynamic build:
First off, make sure you only include the stuff you need (in the project.pro file's QT += core gui network xml lines).
Open the application bundle and remove any unneeded "Qt Plugins" from the bundle. macdeployqt automatically compies all the Qt plugins in there, which can be kind of bulky.
Make sure you are building your application in release mode. Otherwise your application might be linked against the debug libraries of the Qt4 framework, and they are really big (for instance, well over 90 MB for the debug library vs. 16 MB of a release variant without debugging symbols). This might be what happened in your case.
If you have a large application binary, you can use UPX to compress your executable file by 40-50%.
Other than that, you should use compressed disk images to deploy your application.
One of my projects uses QtGui, QtNetwork, QtCore and QtXml and the resulting bundle is about 16 MB in size.
Hope that helps.
Unfortunately you will have to include the Qt libraries you need into your own bundle, as you cannot expect your users to have Qt installed on Mac (whereas on Linux packaging systems allow you to require at least a given version of Qt.
There is a nice tool to help you with that, which is called macdeployqt. You just need to invoke it on your bundle application and it will pack the required libraries, changing the linkage of your binary to refer to them. Without it, making bundles for Mac is a real pain (it still is, but considerably less though).
http://doc.trolltech.com/4.6/deployment-mac.html#the-mac-deployment-tool
Afterwards, you can make a .dmg image as you would do with any other app. There is an option in macdeployqt that builds a basic one.
On Linux, it's better to rely on the OS's copy of Qt, as it's almost certainly installed - for OS X, almost all apps use a statically compiled library.
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.