Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Request: MUSL x-compilation target #224

Open
sempervictus opened this issue Apr 21, 2021 · 3 comments
Open

Request: MUSL x-compilation target #224

sempervictus opened this issue Apr 21, 2021 · 3 comments
Labels
enhancement New feature or request

Comments

@sempervictus
Copy link

The currently supported targets list includes a bunch of GNU target toolchains, but none on MUSL. In order to build fully static binaries - like something one might want to run inside the initramfs, we need to separate from whatever libc is used by the rest of the host inside that target as it might change and break critical paths accessing the TPM before a full userspace is available. The crate page has a link to how cross compiles are set up in the buildbots, but leads to a missing page - We include cross-compilation builds as a nightly check in Github Actions - you can find them here as an example of the steps needed
Is there a writeup somewhere on how to set this up, or possibly a way to include pre-built targets?

@hug-dev
Copy link
Member

hug-dev commented Apr 21, 2021

Hey 👋!
Thanks for the issue!

First about the link, it should point to this file. Looks like relative links to file do not work well with crates.io! Fixed it in #225

About target support, I guess yo ugot the panic message saying that the target is not supported? We modified the way we check for supported targets only verifying for the target architecture and OS (see #219) but not making any difference if the target has a GNU or MUSL environment. That would mean that both x86_64-unknown-linux-gnu and x86_64-unknown-linux-musl for example would be treated the same way by our build script. If the bindings for those two targets would be different, maybe they should be treated differently btw. We did not yet release that change however!

I hope that would help? Feel free to say if I am wrong or you were having a totally different problem 😋

@hug-dev hug-dev added the enhancement New feature or request label Apr 21, 2021
@hug-dev hug-dev added this to All issues in Parsec via automation Apr 21, 2021
@ionut-arm ionut-arm removed this from All issues in Parsec Oct 11, 2021
@nightmared
Copy link

FWIW I was able to successfully build a static binary using the following Dockerfile (that builds atop the "famous" clux/muslrust):

# Note: for safety, please build the mulsrust image yourselves (this will help against supply chain attacks):
# https://github.com/clux/muslrust/blob/main/Dockerfile
FROM clux/muslrust:stable

RUN apt update && apt install -y libclang-15-dev clang-15 git meson ninja-build bison gettext autopoint libltdl-dev pkg-config autoconf-archive && rm -rf /var/lib/apt/lists/*
WORKDIR /
RUN curl -sSL https://s3.amazonaws.com/json-c_releases/releases/json-c-0.17-nodoc.tar.gz | tar xz && mkdir json-c-0.17/build && cd json-c-0.17/build && cmake .. -DBUILD_STATIC_LIBS=ON -DBUILD_SHARED_LIBS=OFF -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=$PREFIX && make -j8 && make install && cd .. && rm -rf json-c-0.17
RUN git clone --depth 1 https://github.com/util-linux/util-linux.git && cd util-linux && ./autogen.sh && ./configure --enable-static --prefix=$PREFIX --host=x86_64-unknown-linux-musl --disable-shared --disable-all-programs --enable-libuuid && make -j8 && make install && cd .. && rm -rf util-linux
RUN git clone --depth 1 -b 4.0.x https://github.com/tpm2-software/tpm2-tss.git && cd tpm2-tss && ./bootstrap && CFLAGS="-Wno-error" ./configure --disable-doxygen-doc --enable-static --prefix=$PREFIX --host=x86_64-unknown-linux-musl --disable-shared && make -j8 && make install && cd .. && rm -rf tpm2-tss
WORKDIR /volume

And then building my binary works as follows:

docker build -t musl_with_tss .
docker run -v $PWD:/volume --rm -t -v cargo-cache:/root/.cargo/registry musl_with_tss cargo build

So I don't believe there is any blocking problem for building static binaries with this crate, even though I guess a more integrated solution wouldn't be scorned at.

@nightmared
Copy link

EDIT: turns out it's not that simple, because you need to build tpm-tss with the --enable-nodl flag, otherwise your program will attempt to perform dlopen of the tcti backend (e.g. device), and it won't work with musl

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants