Where could I acquire a working copy of compiled JavaFX app bundled with JRE so I could execute this app on ARM linux?
or
How can I create my JavaFX app + JRE bundle that would work on ARM Linux
Best case scenario for me would be to be ableto create copy-paste enabled folder tree or single executable file..
I do understand that this question might be too vague, but I desperately need some help on this. I have spent more than 6 evenings + 2 nights searching how to get a compiled JavaFX application ( .jar file) to run on ARM linux on UDOO (RPi2-like) board.
I have been more of an .NET guy a long time, and now I had to make WPF-like rich UX app that would run on this specific hardware, and I chose JavaFX due to its likeliness to WPF. It does run fine on my desktop PCs but I absolutely can not get it to run on ARM linux.
I am trying to do this too. Did you get it working? My solution is to package the JAR using tools provided by IntelliJ or any other IDE, include the JRE in a folder within the app, then write a script that invokes the JAR from the included JRE like:
lib/jre/bin/java -jar runthis.jar
I also tried it for two days now but didn't get it to work.
I use maven in combination with the javafx-maven-plugin to build native installers of an application.
At first I got the error, that the javafx-ant.jar tools are missing:
[ERROR] Failed to execute goal build-jar(create-jfxjar) on project foo:
Execution create-jfxjar of goal build-jar failed: Plugin javafx-maven-plugin or
one of its dependencies could not be resolved: Could not find artifact
javafx-packager:javafx-packager:jar:1.8.0 at specified path
/opt/jdk1.8.0/jre/../lib/ant-javafx.jar
Then I found the ant-javafx.jar in a windows JDK but then another error was reported that linux is not supported with this one. Ok so I downloaded a linux JDK and used that ant-javafx.jar. Now it could build and create a *.deb file successfully!
However when I started the installer it failed with a message and when checking the log (/var/log/apt/term.log)
Log started: 2021-04-29 00:40:01
dpkg: Error creating archive
/home/pi/Foo/target/jfx/native/foo.deb (--unpack):
package architecture (amd64) does not match system (armhf)
Then I did research and found the following mailing list entry:
[...] the Java Packager isn’t shipped with any ARM builds that I’m aware of. Currently it is only for X86 Windows, Linux and Mac. [...]
This basically explains it: The packager doesn't work on ARM for now. Maybe we should write the guy to encurage him to add it...
=> So for now I work with the jar directly.
Related
Installation vscode
I'm running Arch Linux (Manjaro) and installed vscode with:
sudo pacman -S code
but then a simple .NET core program resulted in
--------------------------------------------------------------------------------
You may only use the Microsoft .NET Core Debugger (clrdbg) with Visual Studio
Code, Visual Studio or Visual Studio for Mac software to help you develop and
test your applications.
--------------------------------------------------------------------------------
It seems like the official Microsoft build should be obtained via the snap store:
sudo snap install code --classic
And the program looks normal. I can install plug-ins, create a new file et cetera.
Problem
However, I cannot open any files or projects. Doing so results in vscode crashing. I read that code --disable-gpu could solve this problem, but doesn't do so for me.
Any ideas
what may cause this crash?
or how to get the pacman vscode working?
Logs
$ code --verbose
Gtk-Message: 22:59:19.805: Failed to load module "canberra-gtk-module"
Gtk-Message: 22:59:19.805: Failed to load module "canberra-gtk-module"
(code:33833): GdkPixbuf-WARNING **: 22:59:19.817: Cannot open pixbuf loader module file '/usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders.cache': No such file or directory
This likely means that your installation is broken.
Try running the command
gdk-pixbuf-query-loaders > /usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders.cache
to make things work again for the time being.
[33863:1104/225919.911481:ERROR:appcenter_api.cc(52)] expecting appcenter url prefix
[main 2020-11-04T21:59:19.960Z] Sending env to running instance...
[main 2020-11-04T21:59:20.041Z] Sent env to running instance. Terminating...
[main 2020-11-04T21:59:20.041Z] Lifecycle#kill()
where the recommended gdk-pixbuf-query-loaders > /usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders.cache results in bash: /usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders.cache: No such file or directory
I'm running Arch Linux (Manjaro) and installed vscode with:
sudo pacman -S code
but then a simple .NET core program resulted in
--------------------------------------------------------------------------------
You may only use the Microsoft .NET Core Debugger (clrdbg) with Visual Studio
Code, Visual Studio or Visual Studio for Mac software to help you develop and
test your applications.
--------------------------------------------------------------------------------
I had the same issue trying to get the debugger to work and I spent hours on finding the reason for this. What I found out is that the debugger only works with officially signed Microsoft binaries of VSCode. So you have to make a distinction here:
The package code contains the open source version of visual studio code, a build wich anyone can make using the provided sources by Microsoft. The program which you get here is therefore not signed by MS!
The package visual-studio-code-bin provided by the AUR contains a officially signed version by MS. If you use this package, the debugger works as expected.
I do not know wether snap - which I personally never used at all - provides this kind of package, so I can not tell anything about that, but using the said package from the user repository solved the problem for me reliably.
Try this one (which I installed just yesterday under the recent manjaro distribution and it worked fine) and see if this solves your problem with opening files and folders.
I am trying to configure Eclipse for building a custom kernel module. For that, I am using my own custom makefile, which is not managed by Eclipse. I have got everything working (the code compiles), apart of the IDE "seeing" all of the sources and not yielding errors:
I tried following this guide: Configuring Eclipse for Linux Kernel module development but it did not help me.
Running a TeamCity build agent to run NUnit tests on Ubuntu 14.04 LTC with the latest build of mono appears to have some dependency issues that I cant for the life of me solve.
I have followed the following installation steps
Mono Installation Steps for 4.0.1
Team City Build Agent
When the TC Build Agent starts the NUnit step, it simply fails, and looking at the logs shows it executes
/usr/bin/mono-sgen /home/ubuntu/buildAgent/plugins/dotnetPlugin/bin/JetBrains.BuildServer.NUnitLauncher.exe
which promptly returns with
Corlib not in sync with this runtime: expected corlib version 117, found 111.
Loaded from: /usr/lib/mono/4.0/mscorlib.dll
Download a newer corlib or a newer runtime at http://www.mono-project.com/download.
Is there any possible way to get this to work? I have tried removing all the pieces and re-installing again and even installing a older version of mono build but to no avail.
The TC connection appears to work and I can manually invoke and call mono on its own and even nunit-console however this .exe build provided by TC seems to have be stumped as linux non-expert.
Please save me from dependency hell!!
Edit: I ended up just solving my problem by installing nunit-console and enabling the XML Report processing build feature rather than play around with the corelib files and break something else.
This is a Mono bug, see https://bugzilla.xamarin.com/show_bug.cgi?id=34675.
The problem is that Mono moved to providing the 4.0 assemblies, including mscorlib.dll, only in form of reference assemblies. They contain only metadata and are intended for the compiler. Normally applications just use the newest version automatically.
The loader code in Mono however wasn't updated to bind forward an explicit runtime version of v4.0.20506 or v4.0.30128 which TeamCity is using in their .exe.config files to the latest version. The runtime instead tries to load mscorlib.dll from the 4.0 directory and bails as the version is too old (it's from the time the reference assemblies were generated).
As a workaround, you can edit <build agent
installdir>/plugins/dotnetPlugin/bin/JetBrains.BuildServer.NUnitLauncher.exe.config (and other .exe.config files)
and remove the following lines:
<supportedRuntime version="v4.0.20506"/>
<supportedRuntime version="v4.0.30128"/>
This might stop working once TeamCity decides to update the plugin though.
Replacing the mscorlib version is only asking for trouble - i.e. TypeLoadException's and friends are waiting around the corner to get you.
What I did was replace the Teamcity build step with a manual invocation of the TC NunitLauncher, but forcing it to use Mono 4.5:
mono --runtime=4.5 /Applications/buildAgent/plugins/dotnetPlugin/bin/JetBrains.BuildServer.NUnitLauncher.exe v4.0 MSIL NUnit-2.6.3 $(find **/bin/Release/*Tests.dll | paste -sd ";" -)
The invocation uses some shell trickery to find all assemblies I'm interested in using a wildcard, but other than that should be straightforward to understand.
It would be nice if Mono fixed their broken 4.0 runtime. Anyone already reported it on https://bugzilla.xamarin.com/ ?
This is how I worked around it : (note my mono is in /opt/mono)
$ cd /opt/mono/lib/mono
$ sudo mv 4.0 __4.0
$ sudo ln -s 4.5 4.0
i.e get rid of the 4.0 folder and symlink the 4.5 to be 4.0
This is something of a hack but it got me up and running until a proper fix surfaces!
Steve
I had this problem on my Raspberry Pi after compiling 4.0.2 but it was loading from /4.5/
This got me going:
sudo mv /usr/lib/mono/4.5/mscorlib.dll /usr/lib/mono/4.5/_old_mscorlib.dll
sudo cp /opt/mono-4.0.2/lib/mono/4.5/mscorlib.dll /usr/lib/mono/4.5
I've downloaded the latest version of CefGlue as well as the corresponding CEF binaries. I can get the demo examples to run fine in Windows, but the Linux GtkSharp demo does not run. It compiles fine under MonoDevelop on my Linux box but throws a DllNotFoundException: libcef
I've put the libcef.so in the executable directory as well as running ldconfig in the CEF release directory.
I'm new to Linux, so there's probably something simple and obvious that I'm missing.
The answers on this Bitbucket issue explain how the library path resolution can be fixed.
Unfortunately, this Bitcuket issue goes on to explain that Linux support is broken and the maintainer Dmitry says that he doesn't have the resources to support linux.
I recently began learning wxWidgets. As all learners do, I first wrote and tested the Minimal App (on my Ubuntu 12.04 LTS). It worked like a charm.
I then decided to test the application on my Windows 7 PC. I built wxWidgets (Debug and Release builds) using Visual C++ 2008 Express following instructions from here. I also built the Minimal App (Build and Release configurations) following the same instructions. The application worked perfectly on my computer. To check whether there were any problems, I sent the executable to a friend of mine. He tested it on his XP PC and it gave him the following error:
The application has failed to start because its side-by-side configuration is incorrect. Please see the application event log for more details.
I have checked that I am using the Multithreaded setting in the build options for both the Debug and Release versions of my application. However, neither of the generated executables works on my friend's machine.
What am I missing out here?
You are missing the C/C++ runtime libraries.
The simplest solution is to build both the wxwidgets libraries and the application with the /MT switch rather than the /MD switch in Project | Properties | C++ | Code generation | runtime libraries