Makefile: Make all builds explicitly fully static (disable CGO)

[JoeKar]

Due to this the "Linux 64 fully static" has been marked deprecated and is only kept for compatibility with:
https://github.com/benweissmann/getmic.ro/blob/f90870e948afab8be9ec40884050044b59ed5b7c/index.sh#L197-L204

Fixes #3463

[dmaluka]

Shouldn't we just set CGO_ENABLED=0 in Makefile instead?
We don't want unnecessary divergence between released binaries and binaries built manually by the user?

[JoeKar]

Hm, exactly this was my intention in the first place to keep the capability to link it dynamically.
But since the Makefile is indeed the smarter place to do this change we can add a new build target too keep both use cases.

[dmaluka]

Shouldn't we rather ask @benweissmann to update the script?

[JoeKar]

I directly provided the PR: benweissmann/getmic.ro#40
But we've to keep in mind, that this will take effect earliest with the upcoming release.

[dmaluka]

But we've to keep in mind, that this will take effect earliest with the upcoming release.

Sh*t... so this means that if we remove linux64-static and merge benweissmann/getmic.ro#40, getmic.ro will be broken for Musl until the next release?

[benweissmann]

I would suggest doing one release where you publish statically-linked binaries using both the old name and new name (i.e., have the same statically linked binary published both with and without the -static suffix). Then, I can update getmic.ro after that release is published to cut over to the new name seamlessly, and future releases can drop the -static suffix.

[dmaluka]

SGTM.

[dmaluka]

Seems a bit messy, and "asymmetric" (no quick version of build-dynamic, no dynamic version of build-dbg). Maybe instead of adding a target, just add a variable, e.g. DYNAMIC? I.e. just:

build-quick:
	CGO_ENABLED=$(DYNAMIC) go build ...

build-dbg:
	CGO_ENABLED=$(DYNAMIC) go build ...

And then we can run DYNAMIC=1 make build or whatever.

Also need to update (i.e. rewrite) the Fully static binary section in README.

[JoeKar]

Damn, this "hidden" darwin dependency tools/info-plist.go 🤦‍♂️
So we've to exclude darwin somehow or can't generalize it in the Makefile.

Maybe define ADDITIONAL_GO_LINKER_FLAGS to be empty and extend it only in case the GOOS is darwin and forcing CGO_ENABLED to be 1 afterwards. 🤔

[dmaluka]

Yeah, my first thought was: what the hell is this plist and can we just get rid of it or its -linkmode external. But it is not obvious if it is possible and how, and I have no wish to figure that out.

Maybe define ADDITIONAL_GO_LINKER_FLAGS to be empty and extend it only in case the GOOS is darwin and forcing CGO_ENABLED to be 1 afterwards. 🤔

Seems to make sense.

[dmaluka]

BTW found its roots: #513

[JoeKar]

Maybe define ADDITIONAL_GO_LINKER_FLAGS to be empty and extend it only in case the GOOS is darwin and forcing CGO_ENABLED to be 1 afterwards. 🤔

Should do the trick (for) now.
But to be honest, this kind of meta info is only included in the moment micro is natively build on macOS. It's completely missing, at least since the builds are cross compiled via GitHub actions, in our prebuilt binaries. 🤷‍♂️

[dmaluka]

Yeah, I've just realized that, after looking at GOHOSTOS in your patch.

Which makes this feature from #513 even more... interesting.

[dmaluka]

Although before 6945aa3 this feature was used for cross-compiled binaries as well... but I doubt it was really working correctly.

[dmaluka]

Now, should we document this (the fact that MacOS builds are an exception, but only native ones) in README as well?

[JoeKar]

Yep, better to document before someone is complaining.

Although before 6945aa3 this feature was used for cross-compiled binaries as well... but I doubt it was really working correctly.

Me too, since building micro with darwin AND CGO_ENABLED=1 requires clang.
We could try it with GOOS instead of GOHOSTOS as switch, but then we most probably run into trouble cross compiling for darwin where clang is not available. This might hit the GitHub actions etc.pp