I am currently working on a Julia API to SLINT (https://slint.dev/) which is a GUI library for Rust.
For me it started as fun project to learn Rust, but it turned out to be tedious. I actually need some help to get this on track… I think it needs some experienced Rust developer.
Individual packages may still do things that result in un-relocatable images. In my experience, it’s pretty hit-and-miss, depending on the package.
So we need a tutorial that explains how to test and how to avoid un-relocatable images.
GLFW_jll.jl currently requires > 70 dependencies
If I understand GLFW: Compiling GLFW
To compile GLFW for Wayland, you need to have the Wayland and xkbcommon development packages installed. They are not needed to build or run programs that use GLFW.
And yet for some reason:
(jl_Ht8Yzi) pkg> why Wayland_jll
GLFW_jll → libdecor_jll → Wayland_jll
GLFW_jll → libdecor_jll → xkbcommon_jll → Wayland_jll
GLFW_jll → xkbcommon_jll → Wayland_jll
Even stranger is the dependency on XML2_jll.jl XML2 is a bloated xml parsing library with over 100K lines of C code, for reference XML.jl is less than 1K lines of Julia.
(jl_Ht8Yzi) pkg> why XML2_jll
GLFW_jll → Libglvnd_jll → Xorg_libX11_jll → Xorg_libxcb_jll → XSLT_jll → XML2_jll
GLFW_jll → Libglvnd_jll → Xorg_libXext_jll → Xorg_libX11_jll → Xorg_libxcb_jll → XSLT_jll → XML2_jll
GLFW_jll → Xorg_libXcursor_jll → Xorg_libXfixes_jll → Xorg_libX11_jll → Xorg_libxcb_jll → XSLT_jll → XML2_jll
GLFW_jll → Xorg_libXcursor_jll → Xorg_libXrender_jll → Xorg_libX11_jll → Xorg_libxcb_jll → XSLT_jll → XML2_jll
GLFW_jll → Xorg_libXi_jll → Xorg_libXext_jll → Xorg_libX11_jll → Xorg_libxcb_jll → XSLT_jll → XML2_jll
GLFW_jll → Xorg_libXi_jll → Xorg_libXfixes_jll → Xorg_libX11_jll → Xorg_libxcb_jll → XSLT_jll → XML2_jll
GLFW_jll → Xorg_libXinerama_jll → Xorg_libXext_jll → Xorg_libX11_jll → Xorg_libxcb_jll → XSLT_jll → XML2_jll
GLFW_jll → Xorg_libXrandr_jll → Xorg_libXext_jll → Xorg_libX11_jll → Xorg_libxcb_jll → XSLT_jll → XML2_jll
GLFW_jll → Xorg_libXrandr_jll → Xorg_libXrender_jll → Xorg_libX11_jll → Xorg_libxcb_jll → XSLT_jll → XML2_jll
GLFW_jll → libdecor_jll → Libglvnd_jll → Xorg_libX11_jll → Xorg_libxcb_jll → XSLT_jll → XML2_jll
GLFW_jll → libdecor_jll → Libglvnd_jll → Xorg_libXext_jll → Xorg_libX11_jll → Xorg_libxcb_jll → XSLT_jll → XML2_jll
GLFW_jll → libdecor_jll → Pango_jll → Cairo_jll → Glib_jll → Gettext_jll → XML2_jll
GLFW_jll → libdecor_jll → Pango_jll → Cairo_jll → Xorg_libXext_jll → Xorg_libX11_jll → Xorg_libxcb_jll → XSLT_jll → XML2_jll
GLFW_jll → libdecor_jll → Pango_jll → Cairo_jll → Xorg_libXrender_jll → Xorg_libX11_jll → Xorg_libxcb_jll → XSLT_jll → XML2_jll
GLFW_jll → libdecor_jll → Pango_jll → Glib_jll → Gettext_jll → XML2_jll
GLFW_jll → libdecor_jll → Pango_jll → HarfBuzz_jll → Cairo_jll → Glib_jll → Gettext_jll → XML2_jll
GLFW_jll → libdecor_jll → Pango_jll → HarfBuzz_jll → Cairo_jll → Xorg_libXext_jll → Xorg_libX11_jll → Xorg_libxcb_jll → XSLT_jll → XML2_jll
GLFW_jll → libdecor_jll → Pango_jll → HarfBuzz_jll → Cairo_jll → Xorg_libXrender_jll → Xorg_libX11_jll → Xorg_libxcb_jll → XSLT_jll → XML2_jll
GLFW_jll → libdecor_jll → Pango_jll → HarfBuzz_jll → Glib_jll → Gettext_jll → XML2_jll
GLFW_jll → libdecor_jll → Wayland_jll → XML2_jll
GLFW_jll → libdecor_jll → xkbcommon_jll → Wayland_jll → XML2_jll
GLFW_jll → libdecor_jll → xkbcommon_jll → Xorg_libxcb_jll → XSLT_jll → XML2_jll
GLFW_jll → libdecor_jll → xkbcommon_jll → Xorg_xkeyboard_config_jll → Xorg_xkbcomp_jll → Xorg_libxkbfile_jll → Xorg_libX11_jll → Xorg_libxcb_jll → XSLT_jll → XML2_jll
GLFW_jll → xkbcommon_jll → Wayland_jll → XML2_jll
GLFW_jll → xkbcommon_jll → Xorg_libxcb_jll → XSLT_jll → XML2_jll
GLFW_jll → xkbcommon_jll → Xorg_xkeyboard_config_jll → Xorg_xkbcomp_jll → Xorg_libxkbfile_jll → Xorg_libX11_jll → Xorg_libxcb_jll → XSLT_jll → XML2_jll
It may be worthwhile to explore whether an artifact overriding mechanism can be used to replace the GLFW library with one installed on the system. This would be a preferable approach to reducing the number of dependencies, as the current approach works well, eliminating as many assumptions about the host system as possible.
Hmm, is there a lowest common denominator host system (or set of host systems) I can test GLFW_jll on to see if it is actually using all of its dependancies in a worst case scenario?
Mirone is a really impressive GUI app. I must have missed that version of Matlab compiler; in my memory there was always a huge runtime. In the case of 6.5, I suspect the small app size is leveraging some sort of Windows .NET framework or maybe even Java. I wonder if the packaged app is similarly small for Mac.
I agree it would be nice to have an easy way to custom package one’s own computational code into a single GUI app. It was kind of possible with Java, Visual Basic, etc. and almost there today with Python. I guess the key is still to leverage a runtime already on most people’s systems. Might get there soon by compiling into Javascript for a mobile web app.
I don’t agree. I am very happy that Julia and many packages bring their own libraries. Only by doing this it is possible to run the same Julia program on many different operating systems and also on many different versions of the same OS. This is one reasons I switched to Julia: I have an old Python program, but it runs only using Python 2.7 on Ubuntu 12.04 because it depends on old system libraries. Never again!
I’m just observing, not advocating. That’s great that you don’t mind libraries, neither do I. But I know a fair number of PhDs who cannot reliably install a CLI Python package from repo, get the dependencies sorted out, and have it running. If it’s a GUI app, say using PyQt, then you’re talking about some big downloads and possibly lengthy dependency resolution. I know only a handful of people who can install and run Julia and packages. The wider world of STEM (outside CS) is just not so computer savvy.
I do think it’s desirable for casual programmers to share apps that are small and one-clickable as @joa-quim seeks. My observation is that such apps are only small these days if there’s a largish runtime already tucked into your system. Which of course is what every OS, browser, JRE, JVM, etc. is doing to become a mainstream platform. I suspect Matlab 6.5 made good use of JRE to make the compiled app small.
Some may remember a brief period when Microsoft Visual Basic made it incredibly easy to write decent GUI apps. Real computations had to be deployed in a dll, but lots of simple stuff could be done in VB alone, with the runtime tucked into Windows. Then things got complicated with dll hell, and Microsoft pivoted to .NET to unify the runtimes but never regained that simplicity in VB or elsewhere.
I managed to create a GUI application (standalone) in Julia for a simple task at my institute without problems using QML and PackageCompiler.jl. Of course, the macOS bundle is about 287 MB, but it is a single click operation to open and I hardly believe that this size matters for a desktop application today.
At the time of Matlab 6.5 the .m the compiler was able to convert the .m code in C and compile it normally. The graphical interface (on Windows) was provided by Intel libraries. Together this is what made (and still does) it possible to create standalone packages like Mirone. Sure, it was not all roses (for example only doubles were allowed) and the whole thing was 32 bits only, but could be done.
I suppose Windows was the only target in such a scenario. Nowadays, however, we want a cross-platform deployment without the developers becoming platform experts and library maintainers. Hence, the most reasonable choice is to ship all libraries and make as few assumptions about the system as possible, even if that means having X libraries while the app runs on Wayland.
If one wants to reduce the size of shipped applications, one can still do so, as I understand, with artifact overriding mechanism. Doing so may or may not work straightforwardly, and one may learn a lot about compilation pipelines, flags, patches and version differences.
For instance, Snap and MSIX package installers support installing shared libraries with specific versions separately. One can shave the resulting installer size by installing Julia runtime and the shared libraries separately. On the other hand, MacOS does not support that; hence, its installers need to ship everything.
One reason I suspect Java is that around that time Matlab introduced Desktop, with entire GUI in Java. It was okay and cross-platform except for slow start-up and memory hogging. Microsoft and Apple used to deploy Java with OS, until they dropped it due to lawsuits and security issues, and Matlab eventually had to pivot away, which may be why later compiled apps couldn’t be small anymore. I also suspect that mirone looked the same on Windows and Mac (or at least not like Mac), which would be unlikely with native GUI calls. This is all hazy memory of course.
This is already possible, these should be the relevant docs: Overriding artifact locations
The registration workflow should catch that. If there is a badge for relocatability it would be great.
Yes, that is the mechanism I meant. One needs to explore if application libraries are overrided with the host system-provided ones, would they still work. There may be pitfalls hidden in how libraries are compiled, linked, or patched, so I wouldn’t expect to be easy unless we are lucky.
I live in that “wider world”, and though I agree many of the colleagues are not computer savvy, each of them would be able to install Julia via juliaup and one package according to provided instructions.
OK, the last time a guy ignored my advice to use juliaup, he downloaded Julia and then needed my help, but if you write “install Julia using juliaup according to…” in large enough letters 
, most people would do it, and it works.
This libdecor issue for a “self-contained” plugin might also help.
I noticed that no one mentioned FLTK, so decided to give my 2 cents.
FLTK is lightweight, cross-platform GUI lib written in C++. Its lightweight design is twofold: Not only the library size is small and can be statically linked, but also it does not use some “modern” C++ features, which means wrapping it in Julia should not be possible.
The main “problem” of this library is, arguably, the archaic design of the widgets, but I think this is not a big issue for most scientific computing software. On the other hand, although the project started long time ago, it is still under active development, and just released a new version which supports Wayland on Linux and HiDPI in different platforms.
Given it does not use advanced features of C++, calling it from C++ should be possible. Also, I found a C binding https://github.com/MoAlyousef/cfltk which might be called directly from Julia. (The same author made a popular Rust binding for FLTK, based on this C binding.)
Nice discovery.