musl-based linux distro support

[DylanDoesProgramming664]

added a switch statement to linker.c to link to /lib/ld-musl-x86-64.so.1 if being compiled from source on a musl-based x86-64 linux distribution.

[lerno]

Very interesting. I'll have a look later.

[lerno]

Could we have some way to verify musl on CI? It would be great, because otherwise this could accidentally break without anyone noticing.

[DylanDoesProgramming664]

Alright, I'll see if I can figure out how to set up tests for an Alpine or Void instance, since either one can run as a musl-based distro. Though, I don't believe either one has static libraries for lld in their repositories, so I'll have to figure out how to get them on the instance through other means. I've been currently using TinyGo's Makefile to fetch resources for static lld and llvm libs.

[DylanDoesProgramming664]

Alright, I'll see if I can figure out how to set up tests for an Alpine or Void instance, since either one can run as a musl-based distro. Though, I don't believe either one has static libraries for lld in their repositories, so I'll have to figure out how to get them on the instance through other means. I've been currently using TinyGo's Makefile to fetch resources for static lld and llvm libs.

Okay. I'll just have an Alpine test using the dynamic libraries for lld and llvm now, since that is what's ordinarily available.

[DylanDoesProgramming664]

Sorry about all of that. Not used to writing or editing github workflows at all, so I apologize for any inconvenience.

[lerno]

No problem. We're almost there. But something seems to fail in that project building step.

[DylanDoesProgramming664]

Yep. It is --linker=builtin. It binds falsely to /lib64/ld-linux-x86-64.so.2 irrespective of libc implementation or host architecture. when that flag isn't used, it gets the host cc to link it, which works as expected. To fix this, we'll need a double-switch statement for the platform architecture and environment in order to assign the appropriate /(lib64|lib)/ld-(linux|musl)-<libc-host-arch>.so.(1|2).

[DylanDoesProgramming664]

I'll be working on linker.c, target.c, enums.h, and a few other places related to target triples and linking to get it to look in the right places for everything. There are issues with other commands passed as well regarding musl, so I'll be working on it before work, when I get home tonight and tomorrow morning.

[DylanDoesProgramming664]

I'll be working on linker.c, target.c, enums.h, and a few other places related to target triples and linking to get it to look in the right places for everything. There are issues with other commands passed as well regarding musl, so I'll be working on it before work, when I get home tonight and tomorrow morning.

Just a quick update and inquiry. I'm using rootfs tarballs of Alpine Linux, Debian and Void Linux (glibc and musl) to get a small sample size of ld locations for linux-gnu variants over linux-musl ones. surprisingly, looks like for all of them, be it glibc or musl-based, /lib64 isn't in any of the rootfs tarballs by default, meaning that it's a symlink put into some of these filesystems during installation. Does anyone know of any distros that use /lib64 as a standalone directory for a Linux distribution over being symlinked to /lib or /usr/lib?

[DylanDoesProgramming664]

Just a quick update and inquiry. I'm using rootfs tarballs of Alpine Linux, Debian and Void Linux (glibc and musl) to get a small sample size of ld locations for linux-gnu variants over linux-musl ones. surprisingly, looks like for all of them, be it glibc or musl-based, /lib64 isn't in any of the rootfs tarballs by default, meaning that it's a symlink put into some of these filesystems during installation. Does anyone know of any distros that use /lib64 as a standalone directory for a Linux distribution over being symlinked to /lib or /usr/lib?

I just found the llvm-project's llvm-project/clang/test/Driver/linux-ld.c. This contains all of the paths for ld-linux, ld-musl, crt, distro-specific libs, etc used by clang.

[lerno]

It would be awesome to incorporate all of those.

[DylanDoesProgramming664]

It would be awesome to incorporate all of those.

Agreed. I'm scanning through all of the driver tests for clang to incorporate as much as I can into linker.c for builtin linking. Also trying to find out exactly when the compiler fetches environment information to ensure we have that when doing linking.

Also, real quick, does anyone care for dietlibc or uClibc support? I already have a check for musl added to builder.c (not yet committed), but I can add some checks for the others if there's interest. Otherwise, it can be made simpler by solely focusing on glibc and musl exclusively.

[lerno]

We can probably stick to musl & glibc for now.

[DylanDoesProgramming664]

Sounds good. Keeps things simple.