Static linking mode fails on Arch Linux about crystal HOT 8 CLOSED

The simple answer is I was unaware of that page in the docs until you linked it 😅

from crystal.

My understanding is this is kinda expected. Even if you could get .a file for libgc and libevent, you're still going to be limited given arch uses glibc, which doesn't play well with static linking. At which point you could have other libs statically linked while dynamically linking libc.

Not really sure there's anything actionable here?

Related: https://crystal-lang.org/reference/1.11/guides/static_linking.html

from crystal.

The problem probably can't be fixed but maybe it could be signposted better? Some ideas:

• The flag could be removed entirely in Arch builds (not great, might be confusing)
• The flag could refuse to execute in Arch builds and instead print a message explaining the situation (better, but still might be annoying for people who want to hack together something that works on Arch)
• The flag could try to execute, fail and then deliver a message that more clearly explains the issue without reference to Debian-specific functionality (probably the best option)
• Crystal could ship with its own copies of these libraries on Arch, enabling the feature to work (don't know how practical this is)

from crystal.

FWIW the messaging you see isn't from Crystal, but instead from the linker ld; so a bit outside of the control of Crystal itself. The Arch build is also a community thing, and not officially maintained by the core team. If the maintainer of it wants to ship additional libraries with it that would be on them. But in the end wouldn't make all that much of a difference since you'd still have to work around glibc; but would at least allow only having a single dynamically linked lib vs all three (or four).

In the end what's your use case for wanting to link statically on Arch directly? Easiest solution is to do what the docs suggest and do that via Docker and Alpine. Could consider proposing some changes on the forums https://forum.crystal-lang.org/ for discussion until something actionable is determined. But don't really think having Arch specific behavior is the way to go.

from crystal.

My use case is deploying an application written in Crystal to a virtual machine in the cloud. It's quite a predicament.

• My desktop runs Arch Linux.
• The virtual machine cannot be Arch itself because I don't believe Arch builds for AWS are available anymore.
• The virtual machine is too weak to build the application locally. The Crystal compiler consumes far too much memory. It can be made more powerful but that requires going up a full two cost classes with AWS (from t3.nano to t3.small) for an operation that only needs to be performed sporadically.

Compiling locally, copying over the required shared libraries and then running the executable with LD_LIBRARY_PATH=. worked for a while until the version sync between Arch and Ubuntu became too bad and libc broke. I then tried this static linking approach only to discover it was broken. Now I have a much more powerful Ubuntu virtual machine locally which I use to do a compilation against Ubuntu libraries which will hopefully be a permanent solution to the problem.

The root cause is really the memory consumption of the compiler: there exist relatively roomy environments (0.5 - 1 GiB of memory, potentially larger depending on the size of your program) where the final binary would run great but the compiler necessary to produce that binary cannot run. But there already seems to an issue open for that (#12879) and it sounds extremely difficult to fix.

from crystal.

But why don't you just use the Official Alpine Docker image to build a fully static binary? This would allow you to just copy the built binary to your VPS and not have to worry about about copying shared libs, or having extra VMs.

from crystal.

Haha fair enough. That's ultimately your solution. Just works wayyy better for static linking, and can do it within a single command.

from crystal.

• The flag could be removed entirely in Arch builds (not great, might be confusing)
• The flag could refuse to execute in Arch builds and instead print a message explaining the situation (better, but still might be annoying for people who want to hack together something that works on Arch)

Both wouldn't be good solutions. As a compiler flag, --static works completely fine on Arch as on any other system. It's some dependencies that have issues with static linking. But that's not the compiler's fault. You can technically build statically linked programs perfectly fine on Arch as well. Just not when linking against the default C standard library.

• The flag could try to execute, fail and then deliver a message that more clearly explains the issue without reference to Debian-specific functionality (probably the best option)

Yes, it would probably be helpful to improve the error message related to link failures with --static. Especially when building for targets that are known to be problematic in that regard.
What do you mean with "Debian-specific functionality" though?

• Crystal could ship with its own copies of these libraries on Arch, enabling the feature to work (don't know how practical this is)

That won't work. As @Blacksmoke16 already mentioned, the static versions of some libraries (such as libgc) could indeed be provided (and we do/did that), but the main issue is with glibc which is harder to integrate. This might be an option to explore for downstream package maintainers, but I don't think it's a feasible task for the Crystal project.

from crystal.