Static linking

[phorcys420]

Was wondering if anyone ever did manage to compile a giu/imgui-go binary for linux with static-linking.
You can see the message I sent to one of my friends (of course they had no clue) (I was using imgui-go at the time but the "problem" is the same with giu):

trying to compile an imgui-go (https://github.com/inkyblackness/imgui-go/) project with static linking.
the normal command, go build -x -o dist/ src/main.go works fine.

imgui-go is go bindings for Dear ImGui, which of course needs to use CGO.
it depends on GLFW, Xrandr & some other GL stuff.

The following command is what I first tried to use:
go build -tags osusergo,netgo,static -ldflags="-linkmode external" -x -o dist/ src/main.go

it seems to work just fine on my machine, but when running it on another machine it just exits with "no such file or directory", so it seems that I am not properly doing the static linking, but how would I go on about doing that? 

I can say that both the machines run Linux distributions (compile machine is Fedora/Alpine and the other test machine is Artix).
They both have the same Go version (1.17.5) even though I know it has nothing to do with that dysfunction.

This is more of an "ask for help" than an "issue" to be honest, I just don't know where else to ask.

[gucio321]

@phorcys420 I'm running the following go build -tags osusergo,netgo,static -ldflags="-linkmode external" -x -o dist.bin examples/widgets/widgets.go in a giu dir on my fedora linux and it works fine

[phorcys420]

@phorcys420 I'm running the following go build -tags osusergo,netgo,static -ldflags="-linkmode external" -x -o dist.bin examples/widgets/widgets.go in a giu dir on my fedora linux and it works fine

yes, but does it run properly on other machines ?

[phorcys420]

Built on alpine, ran on Artix:

phorcys@thinkbook Téléchargements]$ ./main 
bash: ./main: Aucun fichier ou dossier de ce type
[phorcys@thinkbook Téléchargements]$ ./nonexistingfile
bash: ./nonexistingfile: Aucun fichier ou dossier de ce type

"Aucun fichier ou dossier de ce type" translates to "No such file or directory" (main is the binary, nonexistingfile simply does not exist)

[gucio321]

thats strage... so your issue is that if you're running linux build on another linux machine it doesn't want to run?

(btw, you're sure that main really exists stat main?)

[phorcys420]

(btw, you're sure that main really exists stat main?)

yes it does, I chmod +x'd it just before

[phorcys@thinkbook Téléchargements]$ stat main
  Fichier : main
   Taille : 6934432   	Blocs : 13544      Blocs d'E/S : 4096   fichier
Device: 259,6	Inode: 9046865     Links: 1
Accès : (0755/-rwxr-xr-x)  UID : ( 1000/ phorcys)   GID : ( 1000/ phorcys)
 Accès : 2021-12-21 23:45:31.054078279 +0100
Modif. : 2021-12-21 23:44:50.791970081 +0100
Changt : 2021-12-21 23:45:27.986070237 +0100
  Créé : 2021-12-21 23:44:49.173965611 +0100
[phorcys@thinkbook Téléchargements]$ ./main
bash: ./main: Aucun fichier ou dossier de ce type
[phorcys@thinkbook Téléchargements]$ stat nofile
stat: impossible d'exécuter statx 'nofile': Aucun fichier ou dossier de ce type
[phorcys@thinkbook Téléchargements]$ ./nofile
bash: ./nofile: Aucun fichier ou dossier de ce type
[phorcys@thinkbook Téléchargements]$ 

main -> binary
nofile -> no file
Once again "Aucun fichier ou dossier de ce type" means "No such file or directory"

[gucio321]

strange... sadly cannot test it on another linux platform...
@AllenDang maybe you have possibility to test it?

Including my local build for testing
https://drive.google.com/file/d/107OISX6LSf-EhP3FyVNZUGFD7yeVJ9tM/view?usp=sharing

[AllenDang]

@gucio321 I have zero linux experience...

[gucio321]

meh, so it may be a bit difficult to fix this issue... @phorcys420 does my binary from previous post work on any of your machines?

[HACKERALERT]

For Windows, go build -ldflags="-s -w -H=windowsgui -extldflags=-static" usually works for me. On macOS, I don't think you can statically link, and on Linux, it's somewhat difficult as well. You can, however, build a Snap for Linux that bundles dependencies with it, but that would require Snapcraft to be installed. That's what I've done to distribute my giu app for Linux. Just my 2 cents.

[phorcys420]

meh, so it may be a bit difficult to fix this issue... @phorcys420 does my binary from previous post work on any of your machines?

hmm, you use the same build command as me ?

you can, however, build a Snap for Linux that bundles dependencies with it, but that would require Snapcraft to be installed.

Snap is literal OS cancer and no one should ever have to use it.

[HACKERALERT]

Bro just giving a suggestion, there's no need to call something that works perfectly fine as "cancer".

[phorcys420]

I don't see myself forcing my users to use a "tool" that oversandboxes my software and shims down the user experience for the profit of developer experience. Snap has so many design flaws (e.g forced autoupdating, uses snapd to manage daemons, everything is isolated so are the logs, snapd just slows down my machines)

[HACKERALERT]

Alright, go as you wish. Just don't insult something that works fine for others, especially when it is just a suggestion trying to help you.

[phorcys420]

didn't mean it to look as an insult

[phorcys420]

@gucio321 I can note that your binaries are double the size of mine.

So, there's likely something more in there ;)

[gucio321]

Hehe lol idk what happend iirc i used your build command to create this binarny. However i van rebuild IT obce agai tomorrow

[gucio321]

@phorcys420 I'm running the following go build -tags osusergo,netgo,static -ldflags="-linkmode external" -x -o dist.bin examples/widgets/widgets.go in a giu dir on my fedora linux and it works fine

Maybe gry to build with this command?

[phorcys420]

@phorcys420 I'm running the following go build -tags osusergo,netgo,static -ldflags="-linkmode external" -x -o dist.bin examples/widgets/widgets.go in a giu dir on my fedora linux and it works fine

Maybe gry to build with this command?

it does double the size of my binary, but same end result...

[phorcys420]

I do see some changes between our binaries, even though I use the same command... (main is mine and the .bin one is yours)

[phorcys420]

Compiled on Fedora:

dist/main: ELF 64-bit LSB executable
 x86-64
 version 1 (GNU/Linux)
 dynamically linked
 interpreter /lib64/ld-linux-x86-64.so.2
 BuildID[sha1]=5b46e629db7dce6208521d9888eca8b06461d934
 for GNU/Linux 3.2.0
 not stripped

Compiled on my Alpine build machine:

main: ELF 64-bit LSB executable
 x86-64
 version 1 (SYSV)
 dynamically linked
 interpreter /lib/ld-musl-x86_64.so.1
 Go BuildID=Ti5Y0zPfudi0NkqLPuC9/Ec7mlEoK_LJL5UNuBxc7/MiZnnAhU-WWTFt2kfD1g/1dIoRJyXHl8xrHm8BFih
 not stripped

Alpine uses MUSL ! and NOT glibc!

[phorcys420]

Switched over to a Debian CT for building, works like a charm !
WOOOOOOOOOOOOOOOOOOOOOOOOOOOO !

Remember to check that the libc is indeed the same...