3 ms·

I've done the same alpine trick for static binaries but may I introduce you to musl-cross-make? https://github.com/richfelker/musl-cross-make https://github.co

by ghotli 5y ago

I've done the same alpine trick for static binaries but may I introduce you to musl-cross-make? https://github.com/richfelker/musl-cross-make https://github.com/richfelker/musl-cross-make Just burned out static toolchains that make me static binaries for all architectures gcc supports. Much like musl.cc but they suggest building your own and I do. I use these toolchains on debian (/ anywhere a non-ancient linux kernel runs) to make static binaries, you can too!

electroly 5y ago
When I looked into this, I decided against musl-cross-make because all the tools in there are way out of date. Due to its use of custom patches, you can't easily update it yourself; you must use their specific outdated versions. They're a full major version behind on gcc (it was two major versions behind at the time), and they're two minor versions behind on musl itself. Binutils is five minor versions behind. It was much easier to just fire up an Alpine build container with the latest versions of everything, and I'm actually capable of keeping it up to date. The Alpine folks seem to have more manpower at their disposal for keeping the packages up to date with upstream.
- ghotli 5y ago
  Not an apologist by any means and all that makes sense. I've found it easy and not-a-problem to bump those versions in the config file and made gcc 11.2.0 compilers with everything up-to-date this way quite recently. There's also this fork of MCM that's a fair amount more active, as it backs musl.cc. I probably should have mentioned it https://git.zv.io/toolchains/musl-cross-make https://git.zv.io/toolchains/musl-cross-make Regardless, your argument that a distro taking care of something for you is exactly what they're there for. Makes sense to me. Mostly surfacing that there's multiple ways to handle that sort of thing. I find cross compiling simplest with these and version bumping wasn't a big deal at all compared to the complexities of other ways of cross compiling.
  - electroly 5y ago
    I don't think I had seen that fork before, thanks for the link. They appear to be much more up-to-date. There are still issues using Alpine as a development container. I ultimately resorted to a separate Ubuntu container for development, building against glibc. It was the only way to get VSCode's C++ and debugger extensions to work on aarch64. I don't love the workaround; using Ubuntu for everything would be nicer. I only use Alpine for test and release builds.

by ghotli 5y ago

electroly 5y ago

When I looked into this, I decided against musl-cross-make because all the tools in there are way out of date. Due to its use of custom patches, you can't easily update it yourself; you must use their specific outdated versions. They're a full major version behind on gcc (it was two major versions behind at the time), and they're two minor versions behind on musl itself. Binutils is five minor versions behind. It was much easier to just fire up an Alpine build container with the latest versions of everything, and I'm actually capable of keeping it up to date. The Alpine folks seem to have more manpower at their disposal for keeping the packages up to date with upstream.

ghotli 5y ago
Not an apologist by any means and all that makes sense. I've found it easy and not-a-problem to bump those versions in the config file and made gcc 11.2.0 compilers with everything up-to-date this way quite recently. There's also this fork of MCM that's a fair amount more active, as it backs musl.cc. I probably should have mentioned it https://git.zv.io/toolchains/musl-cross-make https://git.zv.io/toolchains/musl-cross-make Regardless, your argument that a distro taking care of something for you is exactly what they're there for. Makes sense to me. Mostly surfacing that there's multiple ways to handle that sort of thing. I find cross compiling simplest with these and version bumping wasn't a big deal at all compared to the complexities of other ways of cross compiling.
- electroly 5y ago
  I don't think I had seen that fork before, thanks for the link. They appear to be much more up-to-date. There are still issues using Alpine as a development container. I ultimately resorted to a separate Ubuntu container for development, building against glibc. It was the only way to get VSCode's C++ and debugger extensions to work on aarch64. I don't love the workaround; using Ubuntu for everything would be nicer. I only use Alpine for test and release builds.