search

crystal-lang / distribution-scripts

40 stars 24 forks source link

Use clang-8 to build linux libgc and libcrystal #57

Closed bcardiff closed 4 years ago

bcardiff commented 4 years ago

@RX14 do you have any reason to not include this change proposed in the referenced issue?

Fixes https://github.com/crystal-lang/crystal/issues/8653

It fix the 

libgc.a(alloc.o): unrecognized relocation (0x2a) in section `.text'

issue for me locally

j8r commented 4 years ago

It could be better to use the LLVM toolchain everywhere:

Side note: it will result on smaller Alpine containers, the linker being separated from the compiler in the packages.

bcardiff commented 4 years ago

@j8r that is outside of my current goal that is to bring trusty back to the party. My alpine-fu is zero, so I am not sure how to accomplish what you propose. I guess it sounds good.

j8r commented 4 years ago

@bcardiff what I'm essentially saying is in this Dockerfile, both clang and gcc would be used - I suppose it's something better to avoid. Then if clang is used in this file instead of gcc, why not using lld then.

After that, if all works (in theory), there will be size advantage for the built images (maybe for Ubuntu, but especially Alpine)

straight-shoota commented 4 years ago

@j8r Unfortunately, it's not that easy. The crystal compiler doesn't interface with the linker (ld or lld) directly, but invokes the C compiler (CC) which then takes care about configuring the linker. This command is printed when --cross-compile is given. We can use clang as a drop-in replacement for that. Although that adds another dependency again, clang is smaller than gcc, so it would be an net win. Both gcc and clang can be told to use lld as linker. But... when you try that with clang (and no gcc installed), the linker fails because its unable to find libgcc. It seems every Crystal binary is actually linked against libgcc. That's not obvious from the linker arguments generated by the compiler, but added implicitly by cc and clang. I suppose this SO question targets that: https://stackoverflow.com/questions/51173869/why-does-clang-still-need-libgcc-a-to-compile-my-code Maybe it's possible to improve that. But it's probably gonna take some effort. Maybe it could be as easy as providing libgcc as a standalone library. But even that might not be a quick job. While it's generally good to reduce dependencies, the main result would just be that the alpine docker image is a couple of megabytes smaller. To me that's not worth the investment, at least not in the near future.