otoh staticly-linked executables are incredibly stable - it's nice to have that option.

From what I understand, statically linking in GNU's libc.a without releasing source code is a violation of LGPL. Which would break maybe 95% of companies out there running proprietary software on Linux.

musl libc has a more permissive licence, but I hear it performs worse than GNU libc. One can hope for LLVM libc[1] so the entire toolchain would become Clang/LLVM, from the compiler driver to the C/C++ standard libraries. And then it'd be nice to whole-program-optimise from user code all the way to the libc implementation, rip through dead code, and collapse binary sizes.

[1]: https://libc.llvm.org/

▲

teraflop 3 days ago | parent | next [-]

AFAIK, it's technically legal under the LGPL to statically link glibc as long as you also include a copy of the application's object code, along with instructions for how users can re-link against a different glibc if they wish. You don't need to include the source for those .o files.

But I don't think I've ever seen anybody actually do this.

	▲	2 days ago \| parent [-]
		[deleted]

▲

rcxdude 3 days ago | parent | prev | next [-]

Musl is probably the better choice for static linking anyway, GNU libc relies on dynamic linking for a few important features.

▲

resonious 3 days ago | parent | prev | next [-]

The Windows redistributables are so annoying as a user. I remember countless times applications used to ask me to visit the official Microsoft page for downloading them, and it was quite hard to find the right buttons to press to get the thing. Felt like offloading the burden to the users.

	▲	IcyWindows 3 days ago \| parent [-]
		Many installers do it right and don't require the user to do it themselves.

▲

dijit 3 days ago | parent | prev | next [-]

GNU LibC is notoriously difficult to statically link to anyway. (getaddrinfo for example).

Most people use musl, though some others use uclibc.

Musl is actually great, even if it comes with some performance drawbacks in a few cases.

▲

loeg 3 days ago | parent | prev [-]

You can (equivalently) distribute some specific libc.so with your application. I don't think anyone other than GNU maximalists believes this infects your application with the (L)GPL.

▲

Retr0id 3 days ago | parent | next [-]

You'd need to distribute ld.so also, otherwise you'll run into ld/libc incompatibilities.

▲

loeg 2 days ago | parent [-]

Sure.

	▲	account42 a day ago \| parent [-]
		... and ld.so needs to be at a specific absolute path so you can't just distribute it along with your application, you need to use an actual container for this.

▲

cxr 2 days ago | parent | prev [-]

"GNU maximalist" is an odd choice of wording, since it would seem to imply people who are the most well-informed about the project's licenses, but anyone who thinks that distributing an LGPL library without your own app's corresponding source code is someone who flat out doesn't understand the LGPL.

	▲	cxr 2 days ago \| parent [-]
		A mistake in my own wording crept in here; this should have said: > one who thinks that distributing an LGPL library without your own app's corresponding source code is forbidden is someone who flat out doesn't understand the LGPL