Static build?

[probonopd]

Is your feature request related to a problem? Please describe.

I'm always frustrated when applications don't run on my Linux desktop because the developer used a more recent system to compile, making the binary unable to run on my system. I am happy with typical Go programs, because they are linked statically, which means they pretty always run on my machine, as they don't need any libraries on the system.

Is it possible to construct a solution with the existing API?

I don't know

Describe the solution you'd like

Statically linked binaries using Fyne.

Not this:

me@host:~$ ldd fyne_demo 
	linux-vdso.so.1 (0x00007ffd64efa000)
	libGL.so.1 => /usr/lib/x86_64-linux-gnu/libGL.so.1 (0x00007f90fa23c000)
	libX11.so.6 => /usr/lib/x86_64-linux-gnu/libX11.so.6 (0x00007f90f9f04000)
	libXrandr.so.2 => /usr/lib/x86_64-linux-gnu/libXrandr.so.2 (0x00007f90f9cf9000)
	libXcursor.so.1 => /usr/lib/x86_64-linux-gnu/libXcursor.so.1 (0x00007f90f9aef000)
	libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f90f9751000)
	libXinerama.so.1 => /usr/lib/x86_64-linux-gnu/libXinerama.so.1 (0x00007f90f954e000)
	libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f90f934a000)
	librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f90f9142000)
	libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f90f8f23000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f90f8b32000)
	libnvidia-tls.so.340.107 => /usr/lib/x86_64-linux-gnu/tls/libnvidia-tls.so.340.107 (0x00007f90f892f000)
	libnvidia-glcore.so.340.107 => /usr/lib/x86_64-linux-gnu/libnvidia-glcore.so.340.107 (0x00007f90f5d1b000)
	libXext.so.6 => /usr/lib/x86_64-linux-gnu/libXext.so.6 (0x00007f90f5b09000)
	libxcb.so.1 => /usr/lib/x86_64-linux-gnu/libxcb.so.1 (0x00007f90f58e1000)
	libXrender.so.1 => /usr/lib/x86_64-linux-gnu/libXrender.so.1 (0x00007f90f56d7000)
	libXfixes.so.3 => /usr/lib/x86_64-linux-gnu/libXfixes.so.3 (0x00007f90f54d1000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f90fa588000)
	libXau.so.6 => /usr/lib/x86_64-linux-gnu/libXau.so.6 (0x00007f90f52cd000)
	libXdmcp.so.6 => /usr/lib/x86_64-linux-gnu/libXdmcp.so.6 (0x00007f90f50c7000)
	libbsd.so.0 => /lib/x86_64-linux-gnu/libbsd.so.0 (0x00007f90f4eb2000)

[lucor]

Agree it'd be great to have a possibility to create a static build.
The problem is some linux distros could not provide the static package for the CGO dependencies, so in that case we'd recompile them.

For example ubuntu/debian seems not provide the libGL.a: https://packages.ubuntu.com/search?suite=cosmic&arch=any&searchon=contents&keywords=libGL.a

Trying to compile statically on ubuntu, we'll get the following...

CGOENABLED=1 go build -a -ldflags '-extldflags "-static"' .
...
...
/usr/local/go/pkg/tool/linux_amd64/link: running gcc failed: exit status 1
/usr/bin/ld: cannot find -lGL
collect2: error: ld returned 1 exit status

[lucor]

Wondering if this could be solved with fyne-cross.

[andydotxyz]

Yes, fyne_cross could solve it.
However this relates to libc and some cGo complexity as well - see golang/go#26492 for more info.

[probonopd]

Any chance to do without cgo? The way I understand it, Go cross-compilation for other architectures and OSes only works as long as cgo is not used.

[andydotxyz]

Actually cross-compilation is possible with cGo enabled, you just have to add some additional tools. We have the process written up on the website https://fyne.io/develop/cross-compiling.html.

If we did it without cGo we would be relying on software renderers and no graphics card assistance so performance would be significantly degraded.

[probonopd]

Thanks for the explanation @andydotxyz. A big reason for me to use Go is that Go binaries produced on the latest Linux distribution will also run on older target systems. Is this still true when using cGo?

[andydotxyz]

Yes it works on older systems, to an extent. You wound be able to go back to a previous major release. For example if linked to libX11.so.6 it won’t work on a system so old it uses libX11.so.5... honestly I don’t know how far back you can go without trouble. But you could build on the older system if you have trouble :)

[andydotxyz]

Reading more on X11 static linking it seems like it's not recommended.
https://forums.wxwidgets.org/viewtopic.php?t=12454
Unless anyone has thoughts to the contrary I think we should close this request and instead deal with any backwards incompatibility issues as they arise?

[probonopd]

Let's say someone compiles an app on the latest Ubuntu. Will the same binary still run on, say, Ubuntu gutsy?

[andydotxyz]

If the OpenGL library is compatible it should.

Unfortunately if we static compile the GL driver this does not ensure complete compatibility... as well as bigger apps they will be tied to the graphics card vendor so won’t be as portable as you’d like either.

It’s a trade off but I think dynamic linking to the graphics driver is probably best.

[andydotxyz]

Does this issue need further work? I think we reached the conclusion that it's "as static as makes sense"?

[probonopd]

From looking at your answers it seems like dynamically linking or dlopening graphics drivers (such as nvidia) makes sense, while other things could be statically linked. Do I read you correctly? If so, it would be great if it could be done in a way which allows the application to still run on a system that lacks e.g., the nvidia driver, albeit with lower performance.

[andydotxyz]

Yes, Fyne links everything statically apart from the graphics driver (and system APIs such as macOS or X11).
Performance of a non-OpenGL build would likely be terrible and will not get away from the fact that you still have to call out to X11 or win32 to open a window etc.

[andydotxyz]

Perhaps you can share the problem that you are having so we can try and solve it directly?

[probonopd]

I would like to build, ideally without the need for CGo and gcc, a GUI application that will run on any Linux distribution with as few dependencies as possible. Especially, I would like to be able to compile the Go code on e.g., Ubuntu 20.04, and know for sure that the binary will be able to run on, e.g, CentOS 6.

[andydotxyz]

Fyne will probably never work without CGo, the types of system integrations we are aiming to deliver cannot be done without accessing native libraries.

I don’t know how different Ubuntu 20.04 and CentOS 6 are, but until there is a report of what doesn’t work it’s tough to try and fix the issue.

[probonopd]

Fyne will probably never work without CGo

That is unfortunate to hear, but I understand. The main reason I am using Go is that it can compile down to binaries that do not use any libraries from the system, and hence can run on any Linux distribution.

Let's close this here for now, at least until someone can provide a concrete example of incompatibilities.

Thanks for taking the time to respond, appreciate it.

[andydotxyz]

Ok thanks.
It’s worth noting that we are cross compiling Fyne apps, either with local tooling or using fyne-cross, and have not yet seen any linux incompatibilities.