I built CEF 4147 Release x64 binaries to use with CefSharp/84. I used the steps outlined in the CEF MasterBuildQuickStart Wiki. I noticed it generates DLLs, etc that are the same versions as those that come with CefSharp/84. There are some differences, however. The two DLLs in the swiftshshader folder are much smaller and come with LIB files in my build. When I use CefSharp with my CEF build it doesn't work. CefSharp.core.dll cannot load some dependency.
Does CefSharp require any defines that are not used in MasterBuildQuickStart?
I was able to re-create the the CEF binaries that come with CefSharp/84 (CEF build 4147) using the instructions in MasterBuildQuickStart after making the following changes (in bold).
In Step 6:
set GN_DEFINES=is_component_build=false is_official_build=true
# Use vs2017 or vs2019 as appropriate.
set GN_ARGUMENTS=--ide=vs2019 --sln=cef --filters=//cef/*
python ..\automate\automate-git.py --download-dir=c:\code\chromium_git --depot-tools-dir=c:\code\depot_tools --no-distrib --no-build --branch=4147
In Step 7:
set GN_DEFINES=is_component_build=false is_official_build=true
# Use vs2017 or vs2019 as appropriate.
set GN_ARGUMENTS=--ide=vs2019 --sln=cef --filters=//cef/* call cef_create_projects.bat
In Step 8:
ninja -C out\Release_GN_x64 cef
Related
VSCode, Java 11 JavaFX 18.0.2
I am trying to package my code up for distribution as a desktop app. In my case I want a fully self-contained app because of my target user's profile.
I have been through Jenkov add the Oracle docs here and here which suggest I need ant-javafx.jar. That jar file seems to have been dropped from the standard Java SDK some time around Java 7 and put into the regular JavaFX install lib folder.
It's not there in the build I have.
JavaFX seems to have gone to openjfx.io and nowhere in there can I see support for the ant packaging jar. In fact I see openjfx as a retrograde step as they are increasingly forcing everyone into paid plans (try going round and round the loop of downloading anything that doesn't require an LTS payment).
I have a suspicion that there is some silent assumption that everyone will use something from maven or gradle, and maybe the packaging tools are buried away in one of those build tools. For historical reasons I don't use either and it should be possible to do this packaging without one of them.
So where do I get the JavaFX Ant build tasks from without having to pay someone?
I have found that the following works as an alternative with Java 19 and OpenJFX 19. I use the maven-dependency-plugin to copy all the dependency jars (excluding JavaFX, which I use as modules from a "full" JDK [one that includes JavaFX)] into the target/lib directory.
#!/bin/bash
set -o errexit
set -o noclobber
set -o xtrace
# find dependency modules of required modules
DEP_MODS=$(jdeps -quiet --class-path "target/lib/*" --add-modules java.base,java.logging,java.sql,javafx.controls,javafx.fxml --multi-release base --ignore-missing-deps --print-module-deps target/myapp-4.0-beta.jar)
# create a modular runtime image
jlink --compress=1 --no-header-files --no-man-pages --add-modules "java.logging,java.sql,javafx.controls,javafx.fxml,$DEP_MODS" --output target/myapp-4.0-beta
# Example of running it out of the runtime image
# TEST target/myapp-4.0-beta/bin/java -cp "../../myapp-4.0-beta.jar:../../lib/*" org.myapp.App
# symlink to the artifact jar from the lib directory
$(cd target/lib && ln -s ../myapp-4.0-beta.jar)
# use the lib directory and modular runtime image as input to jpackage
jpackage --input target/lib --runtime-image target/myapp-4.0-beta --main-jar myapp-4.0-beta.jar --main-class org.myapp.App --type app-image --app-version 4.0 --name app --dest target/dist/bundle --mac-entitlements src/dist/mac/entitlements.plist
I'm attempting to install OpenSSL on Windows 10 for use with Qt development. I've tried installing from multiple sources, adding lines to my .pro file, and adding DLL files next to the built application, yet nothing works.
I've tried building and running the Qt HTTP request example, and that can't use HTTPS either, so it's not an issue with my code or configuration.
So, where should I get OpenSSL for Windows, and what do I do after installing it?
I've done this before.
For starters, you need to build OpenSSL 1.0.2 source code - available here. You'll need to follow the build instructions in the INSTALL.W32 file. And there are some amended instructions in the INSTALL.W64 file for 64-bit builds.
The two primary DLLs you will wind up building are libeay32.dll and ssleay32.dll. (Also copy off the libeay32.lib and ssleay32.lib stub files and corresponding .pdb files).
If your Qt sources are already built for OpenSSL, you can just drop these two DLLs into your Qt Bin folder (or wherever Qt5Networking.dll is loaded for your application).
If your Qt distribution is built from source, you might need to build Qt again with the openssl-linked option. This will enable Qt to be loaded via implicit DLL loading.
LIB=%LIB%;%c:\openssl\out32dll
configure -commercial release -opengl dynamic openssl-linked -force-debug-info -nomake examples -llibeay32 -lssleay32
jom
For a debug build to correspond to debug Qt5 binaries, you'll need to repeat the above steps, except follow the OpenSSL instructions for building debug binaries to the out32dll.dbg folder.
If your qt distribution was built with dynamic openssl loading, you just need to make sure ssleay32.dll and libeay32.dll are in a folder that is in your PATH environment variable.
I am trying to run a simple GRPC client-server code in raspberri Pi running Raspbian os.
Language that i am using -C# dotnet core (2.1)
I downloaded a sample project from here.
This is a dotnet core project . I am able to run it in Windows environment, i am also able to modify .proto file in this code and run successfully.
I published the solution as it is with command
{ dotnet publish -r linux-arm }
When tried running same on Rpi, i am getting exception. Attached screenshot has the details of it.
Any help to get through this would be of great use
tl;dr The problem is the libgrpc_csharp_ext native library which currently does not get compiled and built for the arm7 processor. I've compiled it (on a pi) for arm7 and released a nuget package to bridge the gap until they support it all the way: https://www.nuget.org/packages/libgrpc_csharp_ext.arm7/
I'll update with a link to a blog post when I finish getting the rest of the tooling and template finished I'm working on.
fuller explanation: the Grpc.Core nuget package contains the native libgrpc_csharp_ext library that the dotnet implementation of grpc loads in NativeExtensions.cs then maps with PInvoke in NativeMethods.Generated.cs. Inspecting that package, you'll see a version of that library in each /runtimes/[win, osx, linux]/native folder. Unfortunately, no linux-arm version of the library is included. However, in the code, if the platform is linux, it will try to load the static library using the name as formatted here. Dissect that a little and you'll see that as of right now, any 'linux' platform that isn't '64bit' (which despite the proc on the pi being 64 bit, the distro of linux you're using on there, including raspbian, likely isn't) will look for libgrpc_csharp_ext.x86.so. When you dotnet publish -r linux-arm, you'll see that library there in the build output, but unfortunately, it's the wrong one (I think publish just grabs 'the closest one' when it can't find a specific library in the runtimes folder).
The nuget package I created above is compiled for arm7 - I actually cloned the grpc repo onto a pi and peeled away enough of the /csharp build to just cmake the libgrpc_csharp_ext. The 'trick' the package uses is to put the library in runtimes/linux-arm/native folder within the package, which dotnet core recognizes when publishing and pulls into the build output - but the library is still named libgrpc_csharp_ext.x86.so because of the way NativeMethods.cs formats the library name.
I have made an application using QtWebKit, Qt4. I have the binary generated in Fedora 16. Now, I want to run that application on another PC (running some other Fedora version), where Qt is not installed. How can I package my Qt application so that it can run on a platform where Qt is not installed? Is there any command line utility as well as QtCreator utility to do so. I have tried "deploy all" command, but it didn't have any affect.
Create an Installer with the Qt Installer Framework and just supply all needed shared libraries (Win/OSX) or compile statically. Under Linux there is always the problem between system-wide libraries or bundled libraries. The documentation https://qt-project.org/doc/qt-5.0/qtdoc/deployment.html should give you a good start
Obviously, you need to have access to the qt libraries, which are exactly the same version that you used to compile your application.
There are two options :
link qt libraries statically
create a RPM package (see this how)
Also check Deploying Qt Applications.
Since you're deploying using rpm, to systems where Qt 4 rpms are available, you don't need to do anything besides simply adding a dependency on the qt to your rpm's specfile. The user installing your package using yum localinstall will get the Qt dependencies automatically installed. That's the correct way of doing it - it will keep your package size small.
Of course you need a separate rpm build for every fedora/centos major version out there, but that's almost always a requirement.
If your package needs newer Qt version than the one provided by the platform packages, you can still make a specific version dependency (say qt >= 4.7.0) and have a readme that indicates that newer packages can be obtained from a 3rd party repository (epel etc.)
For deployment under Linux I've used Bitrock Installer Tool.
The main thing before deploying is to check your dependencies. You can do that by using command:
ldd appName | grep libQt
After that you'll see list of dependencies. You'll have to set environment variable LD_LIBRARY_PATH to let linker know where're your libraries. To do that:
export LD_LIBRARY_PATH=.
. means current directory
And after that:
./appName $*
After that you'll be able to use your executable with Bitrock Installer Tool.
I wanted to migrate my Qt 4 app to use Qt 5 instead. These instructions failed, due to some differences with how MXE builds Qt 5, including the fact that it uses modularised Qt tarballs, instead of one large tarball.
Here are the full instructions:
Get it:
git clone https://github.com/mxe/mxe.git
Install build dependencies
Build Qt 5 for Windows:
cd mxe && make qtbase
This will first build its dependencies and the cross-build tools;
It should take less than an hour on a fast machine with decent internet access.
Due to the new modular nature of Qt 5, various major Qt components are now in different tarballs. The one selected above, qtbase, should give you enough functionality to run ordinary GUI apps, which is all I needed for my own (smallish) app.
If you want to build all of Qt 5 instead, you'll need to run make qt5 (instead of make qtbase). Note that it will take a lot longer to complete, so be sure that you need the extra functionality.
Get to the directory of your app, and run the Qt Makefile generator tool:
<mxe root>/usr/bin/i686-w64-mingw32.static-qmake-qt5
Build your project:
make
You should find the binary in the ./release directory:
wine release/foo.exe
Some notes:
This was tested on my 64-bit Debian 8, and on Windows of course.
The output is a 32-bit static executable, which will work well on 64-bit Windows.
If you want a 64-bit executable, build Qt with:
make MXE_TARGETS=x86_64-w64-mingw32.static qtbase
The default MXE_TARGETS value is i686-w64-mingw32.static.
The git checkout command is not correct. You now have to get their stable branch or it will fail building.
git clone https://github.com/mxe/mxe.git
should be...
git clone -b stable https://github.com/mxe/mxe.git
That alone fixed all my issues with qtbase building but leaving no qt folder when done. Then qt5 target would fail with obscure errors. Deleted folder, checked out stable and it worked flawlessly.
For those who directly want a GCC10 64bit compiled Qt5 (for filesystem lib for example),
Here are the full instructions:
Get it:
git clone https://github.com/mxe/mxe.git
Install build dependencies
Build Qt 5 for Windows with gcc10 64bits plugin activated :
cd mxe && make MXE_TARGETS=x86_64-w64-mingw32.shared MXE_PLUGIN_DIRS=plugins/gcc10 qt5
After 2-3 hours of build you can build your app (in your .pro directory) :
<mxe root>/usr/x86_64-w64-mingw32.shared/qt5/bin/qmake
Export path of compiler & build your project:
export PATH=<mxe root>/usr/bin:$PATH
make
You should find the binary in the ./release directory & start it with wine (or wine64) :
wine foo.exe
I don't really know why, but I needed to add the MXE compiler directory to the wine path because it's couldn't find the DLLs :
WINEPATH="<mxe root>/usr/x86_64-w64-mingw32.shared/bin/" wine64 foo.exe
If you try to do this, for me work fine!
su
mv mxe /opt/mxe
cd /opt/mxe && make