Suggested builder does not work about rust

[matejvasek]

/kind bug

[dmikusa]

Note that build by: pack build apps/rust -b paketo-community/rust -B paketobuildpacks/builder-jammy-base:latest does work fine.

I looked into this some more and I think it's just a case of required dependencies not being present in the tiny builder.

The build works with the base builder image, like you mentioned, but attempting to build with tiny even using the buildpack doesn't work. Furthermore, the error is failing during the compile of a dependency that requires system libraries.

That said, I don't get exactly the same error as you. Mine complains about a compile failure, not failure to find the compiler. I think it's missing some of the build files, probably package libzstd-dev.

        running: "musl-gcc" "-Os" "-ffunction-sections" "-fdata-sections" "-fPIC" "-m64" "-I" "zstd/lib/" "-I" "zstd/lib/common" "-I" "zstd/lib/legacy" "-fvisibility=hidden" "-DZSTD_LIB_DEPRECATED=0" "-DXXH_PRIVATE_API=" "-DZSTDLIB_VISIBILITY=" "-DZDICTLIB_VISIBILITY=" "-DZSTDERRORLIB_VISIBILITY=" "-DZSTD_LEGACY_SUPPORT=1" "-o" "/workspace/target/x86_64-unknown-linux-musl/release/build/zstd-sys-28f86fc799f53a62/out/zstd/lib/common/debug.o" "-c" "zstd/lib/common/debug.c"
        exit status: 127
        running: "musl-gcc" "-Os" "-ffunction-sections" "-fdata-sections" "-fPIC" "-m64" "-I" "zstd/lib/" "-I" "zstd/lib/common" "-I" "zstd/lib/legacy" "-fvisibility=hidden" "-DZSTD_LIB_DEPRECATED=0" "-DXXH_PRIVATE_API=" "-DZSTDLIB_VISIBILITY=" "-DZDICTLIB_VISIBILITY=" "-DZSTDERRORLIB_VISIBILITY=" "-DZSTD_LEGACY_SUPPORT=1" "-o" "/workspace/target/x86_64-unknown-linux-musl/release/build/zstd-sys-28f86fc799f53a62/out/zstd/lib/common/entropy_common.o" "-c" "zstd/lib/common/entropy_common.c"
        exit status: 127

        --- stderr


        error occurred: Command "musl-gcc" "-Os" "-ffunction-sections" "-fdata-sections" "-fPIC" "-m64" "-I" "zstd/lib/" "-I" "zstd/lib/common" "-I" "zstd/lib/legacy" "-fvisibility=hidden" "-DZSTD_LIB_DEPRECATED=0" "-DXXH_PRIVATE_API=" "-DZSTDLIB_VISIBILITY=" "-DZDICTLIB_VISIBILITY=" "-DZSTDERRORLIB_VISIBILITY=" "-DZSTD_LEGACY_SUPPORT=1" "-o" "/workspace/target/x86_64-unknown-linux-musl/release/build/zstd-sys-28f86fc799f53a62/out/zstd/lib/common/debug.o" "-c" "zstd/lib/common/debug.c" with args "musl-gcc" did not execute successfully (status code exit status: 127).


      warning: build failed, waiting for other jobs to finish...
      error: failed to compile `function v0.1.0 (/workspace)`, intermediate artifacts can be found at `/workspace/target`
unable to invoke layer creator
unable to contribute application layer
unable to install single
unable to build
exit status 101
ERROR: failed to build: exit status 1
ERROR: failed to build: executing lifecycle: failed with status code: 51

[dmikusa]

FYI, you can change the stack to:

[stack]
  build-image = "docker.io/paketobuildpacks/build-jammy-base"
  id = "io.buildpacks.stacks.jammy"
  run-image = "docker.io/paketobuildpacks/run-jammy-base"

and it should create a builder for jammy base.

[robdimsdale]

That said, I don't get exactly the same error as you. Mine complains about a compile failure, not failure to find the compiler. I think it's missing some of the build files, probably package libzstd-dev.

I don't have any concerns adding libzstd-dev to the tiny build image, but unless you're statically-linking the app wouldn't this then fail at runtime due to the lack of libzstd?

And I think adding packages to the tiny run image is worth a much more in-depth discussion.

[dmikusa]

@robdimsdale For now, I'm OK holding off. There are just a lot of different libraries that can be added.

If this is a blocker for someone, feel free to open an issue against the tiny stack. There are similar issues you can template.

I'm hopeful that as buildpack extensions pick up steam this will be the route to go for "I need dev lib XYZ".

[matejvasek]

IMO it would be useful to have musl-gcc and static versions of some libraries (e.g. libzstd-static) in builder images so static binaries can be produced. That's what tiny runner is good -- to run static binaries, right?

[matejvasek]

unless you're statically-linking the app

Shouldn't this happen automatically on tiny builder?

[matejvasek]

@robdimsdale wrt static compilation: that's what I want and that's what I would expect to happen, but build image doesn't have musl to do it.

[matejvasek]

I managed to build static library by using -e BP_STATIC_BINARY_TYPE=gnulibc. I would expect that static build is done by default on tiny.

[matejvasek]

It looks like static compilation is attempted but with musl not gnulibc.

[robdimsdale]

I'm confused. We added automatic static support for gnulibc here:

        if staticType == StaticTypeGNULIBC {
                target = "--target=x86_64-unknown-linux-gnu"


                rustFlagsList := []string{}
                if len(rustFlags) > 0 {
                        rustFlagsList = append(rustFlagsList, rustFlags)
                }
                rustFlagsList = append(rustFlagsList, "-C target-feature=+crt-static")
                newRustFlags := strings.Join(rustFlagsList, " ")


                err := os.Setenv("RUSTFLAGS", newRustFlags)
                if err != nil {
                        return []string{}, fmt.Errorf("unable to set env RUSTFLAGS to [%s]\n%w", newRustFlags, err)
                }
        }

Are you saying this doesn't work for you?

[matejvasek]

If I explicitly set BP_STATIC_BINARY_TYPE to gnulibc it works, but I would expect that I do not have to set it by myself. I wish that it was used automatically when image is tiny.

[matejvasek]

It looks like the default is not gnulibc but musl, but musl requires musl-gcc which is not present.

[matejvasek]

Or if musl is supposed to be default then tiny image should contain musl-gcc I think.

[robdimsdale]

Ah, ok. I see. The buildpack code is automatically (and correctly) identifying the stack as tiny, but if you don't provide -e BP_STATIC_BINARY_TYPE=gnulibc it defaults to --target=x86_64-unknown-linux-musl and also does not provide the rust flag -C target-feature=+crt-static.

This works fine in the case where you can dynamically link your app on tiny, but if the tiny run image doesn't contain the libraries you need, your app fails at runtime.

Before I dig into this, note that if you instead use RUST_FLAGS="target-feature=+crt-static" you will still get a statically-linked binary, and that is more idiomatic as it does not rely on BP_ environment variables. You might even have that set in some other tooling, and it would be consistent across buildpacks/non-buildpacks workflows.

That being said, I hear your feedback that you expect your app to just run.

There's two ways to make your app "just run" - and you identify both of them:

1. Add more libraries to the tiny stack run image.
2. Default to static linking when running on the tiny stack.

For 1. - there's a pretty high bar for adding packages to the tiny run image. That stack is more tailored towards Java Native Image apps, where static linking isn't a possibility but yet very few libraries other than libc are required to run the app. We also support Go on the tiny stack, for a similar reason: when dynamically linking a Go app very few libraries are required. As @dmikusa mentioned above, there is no point at which we can say that we have added enough libraries. So I'm pretty reluctant to explore that option.

For 2. - I'm not sure I agree that the default behavior on tiny should be static linking. If you want to statically link, just use the static stack instead. You'll get the same resultant binary but with essentially nothing else on the filesystem (i.e. no libc, etc). The build images have the same set of packages, so if it compiles (with static linking) on tiny it will compile on static.

I do hear the feedback that the tiny stack is somewhat limited in the scope of applications it can support given that the run image has very few libraries. But that is true for many languages. It's just that other languages don't rely on dynamical linking as much (think Java Native Image, Go), so they don't encounter that issue. Equivalently, they can't support static linking so the static stack isn't an option for them.

So maybe the ultimate feedback here @paketo-community/rust-maintainers is that we should more clearly push rust users towards the static stack. Most of the feedback I hear from the paketo rust community is the desire for static apps on minimal filesystems, so maybe we should make that the default in the samples, documentation, etc. Maybe we promote the rust buildpack out of "community" and include it in a (not-yet-released) static builder.

If we go down that path, I think at that point it becomes more justifiable to default to a statically-linked application (vs the current behavior which defaults to dynamic linking even on the static stack).