build rust on x86_64_alpine-linux-musl

[8l]

Hi, i am trying to build on alpinelinux.

i have musl libc based llvm,
https://github.com/8l/llvm2

and trying congfigure rust

$ ./configure --prefix=/usr --enable-clang --build=x86_64-a
lpine-linux-musl --host=x86_64-alpine-linux-musl
configure: looking for configure programs
configure: found program 'cmp'
configure: found program 'mkdir'
configure: found program 'printf'
configure: found program 'cut'
configure: found program 'head'
configure: found program 'grep'
configure: found program 'xargs'
configure: found program 'cp'
configure: found program 'find'
configure: found program 'uname'
configure: found program 'date'
configure: found program 'tr'
configure: found program 'sed'
configure: found program 'file'
configure: found program 'make'
configure: inspecting environment
configure: recreating config.tmp
configure: 
configure: processing ./configure args
configure: 
configure: CFG_LOCALSTATEDIR    := /var/lib 
configure: CFG_SYSCONFDIR       := /etc 
configure: CFG_DATADIR          := /share 
configure: CFG_INFODIR          := /share/info 
configure: CFG_LLVM_ROOT        :=  
configure: CFG_PYTHON           :=  
configure: CFG_JEMALLOC_ROOT    :=  
configure: CFG_BUILD            := x86_64-alpine-linux-musl 
localhost:/work/rust$ ./configure --prefix=/usr --enable-clang --build=x86_64-a
lpine-linux-musl --host=x86_64-alpine-linux-musl
configure: looking for configure programs
configure: found program 'cmp'
configure: found program 'mkdir'
configure: found program 'printf'
configure: found program 'cut'
configure: found program 'head'
configure: found program 'grep'
configure: found program 'xargs'
configure: found program 'cp'
configure: found program 'find'
configure: found program 'uname'
configure: found program 'date'
configure: found program 'tr'
configure: found program 'sed'
configure: found program 'file'
configure: found program 'make'
configure: inspecting environment
configure: recreating config.tmp
configure: 
configure: processing ./configure args
configure: 
configure: CFG_LOCALSTATEDIR    := /var/lib 
configure: CFG_SYSCONFDIR       := /etc 
configure: CFG_DATADIR          := /share 
configure: CFG_INFODIR          := /share/info 
configure: CFG_LLVM_ROOT        :=  
configure: CFG_PYTHON           :=  
configure: CFG_JEMALLOC_ROOT    :=  
configure: CFG_BUILD            := x86_64-alpine-linux-musl 
configure: CFG_ANDROID_CROSS_PATH :=  
configure: CFG_I686_LINUX_ANDROID_NDK :=  
configure: CFG_ARM_LINUX_ANDROIDEABI_NDK :=  
configure: CFG_ARMV7_LINUX_ANDROIDEABI_NDK :=  
configure: CFG_AARCH64_LINUX_ANDROID_NDK :=  
configure: CFG_NACL_CROSS_PATH  :=  
configure: CFG_MUSL_ROOT        := /usr/local 
configure: CFG_EXTRA_FILENAME   :=  
configure: CFG_RELEASE_CHANNEL  := dev 
configure: CFG_DEFAULT_LINKER   := cc 
configure: CFG_DEFAULT_AR       := ar 
configure: CFG_LIBDIR           := /usr/lib 
configure: 
configure: validating ./configure args
configure: 
configure: 
configure: looking for build programs
configure: 
configure: CFG_CURL             := /usr/bin/curl (7.49.1)
configure: CFG_PYTHON           := /usr/bin/python2.7 
configure: CFG_GIT              := /usr/bin/git (2.9.1)
configure: CFG_MD5              :=  
configure: CFG_MD5SUM           := /usr/bin/md5sum 
configure: CFG_HASH_COMMAND     := /usr/bin/md5sum | cut -c 1-8 
configure: CFG_CLANG            := /usr/bin/clang++ (3.9.0)
configure: CFG_CCACHE           :=  
configure: CFG_GCC              := /usr/bin/gcc (6.1.1)
configure: CFG_LD               := /usr/bin/ld (2.26.1)
configure: CFG_VALGRIND         :=  
configure: CFG_PERF             :=  
configure: CFG_ISCC             :=  
configure: CFG_ANTLR4           :=  
configure: CFG_GRUN             :=  
configure: CFG_FLEX             := /usr/bin/flex (2.6.0)
configure: CFG_BISON            := /usr/bin/bison (3.0.4)
configure: CFG_GDB              :=  
configure: CFG_LLDB             :=  
configure: CFG_CMAKE            := /usr/bin/cmake (3.6.0)
configure: CFG_DISABLE_VALGRIND_RPASS := 1 
configure: CFG_LLDB_PYTHON      := /usr/bin/python2.7 
configure: 
configure: looking for target specific programs
configure: 
configure: CFG_ADB              :=  
configure: CFG_ENABLE_CLANG     := 1 
configure: CFG_USING_CLANG      := 1 
configure: CFG_CC               := clang 
configure: CFG_CXX              := clang++ 
configure: CFG_STDCPP_NAME      := stdc++ 
configure: error: unsupported target triples "x86_64-alpine-linux-musl" found
$ 

[nagisa]

x86_64-unknown-linux-musl should be good enough for you.

[japaric]

Unfortunately, you can't bootstrap rustc on a musl system because there is not stage0 snapshot. The only available route is to cross compile from a host with glibc. But there are issues with that approach, see #31322 for details.

[alexcrichton]

Yes unfortunately as @japaric mentioned bootstrapping for Alpine doesn't work right now as there are no compilers which are compiled against MUSL available.

That being said, I'd personally be fine adding a x86_64-alpine-linux-musl target which dynamically links to musl instead of statically, and then we could ship that to work on Alpine I believe.

[japaric]

I'd personally be fine adding a x86_64-alpine-linux-musl target which dynamically links to musl instead of statically, and then we could ship that to work on Alpine I believe.

I'm looking into this but without creating a new target. Instead I'm just hacking the existing x86_64-musl target to make it link dynamically. My goal is to verify that we can build a rustc dynamically linked to musl that actually works (My experiment with a rustc statically linked to musl didn't yield good results...).

But assuming that works...

• I'm wary of equating vendor=alpine to "dynamic linking"; it doesn't feel right. That being said, I don't know where else in the target triple we could encode the information that this target does dynamic linking instead of static linking (Not that the current target triples inform the user about the type of linking they do anyway).
• I bet the other musl based Linux distributions (hmm, Void Linux?) are not going to be happy to have the word alpine in their rustc -V output. 😉
• Will this target set its cfg_vendor field to "Alpine" in its target specification?
• How should users detect that this target links dynamically instead of statically so they can build (build.rs) their C/C++ dependencies correctly (static libraries instead of shared ones)? cfg(all(env = "musl", vendor = "alpine")) or just check if $TARGET contains the "alpine" substring? Or perhaps we should add a new cfg(link = "static")?

[alexcrichton]

@japaric If we do go the x86_64-alpine-linux-musl route I definitely agree it's not great and is a bit of a hack. I wouldn't necessarily think of it as "alpine == dynamic linking" but rather on alpine everyone dynamically links so we wouldn't do much else with alpine in the name. I do agree though that I'd prefer to avoid an explosion of x86_64-*-linux-* triples as it's probably not worth it in the long run.

If we were to do it though I'd imagine that cfg_vendor would indeed be set in the custom target spec and users would detect this through "alpine" in the triple name as well. I think though that gcc-rs, at least, wouldn't have to compile anything any differently.

Note, though, that this isn't the only case of a dynamic vs static libc being a thorn in our side (rust-lang/rfcs#1684), so it may be best to solve this all at once instead of specifically here adding a new alpine target.

[Mark-Simulacrum]

I'm going to close in favor of #31322, since that has a lot more discussion and seems to be a duplicate.

[8l]

thanks, latest alpine linux supports rust now.