To the confused ones: yes, macOS doesn't support building fully static binaries; Apple doesn't provide static system libraries...

Do all libraries get linked statically? even when shared libraries are available? If so, then this looks like an acceptable solution.

Well either way, this should check the darwin flag on the compiled module (this will break cross-compiling).

I think I understand now what this PR is trying to do: leave in asking pkg-config for static libraries but don't force static linking. I'd much prefer to explicitly whitelist relevant libraries for dynamic linking - instead of implicitly falling back to dynamic libraries where static aren't available. --static should be "make a static binary" instead of "attempt to make a static binary".

I don't know much about OSX and I can't remember the details of exactly how this part of the compiler behaves (even though I added the flag), so I might be talking out of my arse.

Cross compilation builds an object file. It's unaffected by the static flag.

There are static libraries on macOS, just not for the core system libs (e.g. crt1.o or equivalents). It's impossible for --static to be "build me a fully static binary" on macOS. This is unsupported, and probably by design.

It would be great to support linking statically what can be by asking pkg-config to prefer static libraries. Alternatives ain't nice —e.g. use --cross-compile to build an object then link manually or make sure there are no shared libraries installed on the system.

@ysbaddaden Yes, they do. Crystal currently provides absolute paths to static libraries if they are found as recommended by Apple when wishing to link statically. I've tested this while creating a pull request for MacPorts to add Crystal. I also had to modify the Link attributes of OpenSSL's libcrypto and libssl to plain Link("crypto") and Link("ssl") (removing the hardcoded -l flags) so they would be statically linked too.

Cross compilation builds an object file. It's unaffected by the static flag.

It'll output the wrong link command though. There's a reason the entire rest of the function (and compiler) uses program.has_flag? instead of {% if flag? %}.

There are static libraries on macOS, just not for the core system libs (e.g. crt1.o or equivalents). It's impossible for --static to be "build me a fully static binary" on macOS. This is unsupported, and probably by design.

I understand that, but currently this PR means that it will fall back to dynamic linking for any librarary, instead of just the select few for which static versions don't exist. That's bad behaviour.

@RX14 I've updated the code to use program.has_flag?.

@straight-shoota I think combining this PR with the other one would be a good idea. Basically, allow static linking as much as possible while showing a warning. Even if the binary isn't 100% statically linked, it's still very helpful due to Crystal's dependence on third-party libs such as libgc.

This pull request is, by far, more useful than merely disabling static compilation on macOS. We can have third party libraries to be statically linked, leaving only the system shared libraries out. I believe this is what we should aim for with the static flag on macOS.

Perhaps --static=prefer as an option to show intention, and allow a tag for documenting its purpose?

Yes, --static={yes, no, prefer} options seem like they describe the behaviour of this PR much better.

Nothing since 2 years, the PR as-is doesn't bring much.
I suggest to close it. If you want to continue to work on it @mohd-akram, be free to re-open it.

Also, readline.cr is no longer present (I think Crystal doesn't depend on it anymore).