Support custom libsasl2 installation dir

[pnehrer]

I wonder if it would be possible to support custom libsasl2 installation prefix, in addition to /usr and /usr/local.

My use-case: I need to build rdkafka against x86_64-unknown-linux-musl in Docker using rust-musl-builder. In order to support this, I first build libsasl2, then indicate that I want librdkafka to link libsasl2 statically at the given install path:

FROM ekidd/rust-musl-builder:nightly-2020-11-19 AS build

# Having rdkafka build its own libsasl2 (feature gssapi-vendored) doesn't work on musl!
# Build it from source and have rdkafka link it in statically.

ENV SASL2_STATIC=1 \
    DEP_SASL2_ROOT=/usr/local/musl

RUN VERS=2.1.27 && \
    cd /home/rust/libs && \
    curl -LO "https://github.com/cyrusimap/cyrus-sasl/releases/download/cyrus-sasl-${VERS}/cyrus-sasl-${VERS}.tar.gz" && \
    tar xzf "cyrus-sasl-${VERS}.tar.gz" && cd "cyrus-sasl-${VERS}" && \
    CC=musl-gcc CPPFLAGS=-I/usr/local/musl/include LDFLAGS=-L/usr/local/musl/lib ./configure --prefix="${DEP_SASL2_ROOT}" \
        --enable-static --disable-shared --disable-sample --disable-checkapop --disable-cram --disable-scram --disable-digest \
        --disable-otp --disable-gssapi --disable-plain --disable-anon --with-dblib=none --with-pic CFLAGS=-fPIC \
        --host=x86_64-unknown-linux-musl && \
    make && sudo make install && \
    cd .. && rm -fR "cyrus-sasl-${VERS}" "cyrus-sasl-${VERS}.tar.gz"

...

RUN cargo build --release

Note that the vendored build using gssapi-vendored seems to fail to link, so I use this:

[dependencies]
rdkafka = { version = "0.24", features = ["cmake-build", "gssapi", "ssl-vendored"] }

[CLAassistant]

All committers have signed the CLA.

[pnehrer]

@benesch do you think this is a viable approach? Any pointers would be greatly appreciated!

[benesch]

Hey, sorry for the delay! I'm not opposed to adding more search prefixes in principle, though I'm not sure DEP_SASL2_ROOT is the right name for the environment variable to control that behavior. The DEP prefix is to me indicates the magic Cargo variables that get passed around.

We could follow the OpenSSL crate here I suppose and use SASL2_DIR as the name of the environment variable.

[benesch]

Better yet, I'd love to make librdkafka just support compilation in the musl builder out of the box. What were the errors you were seeing?

[benesch]

Was it this?

  = note: /usr/bin/ld: /workdir/target/x86_64-unknown-linux-musl/debug/deps/libsasl2_sys-04250f7405343342.rlib(dnsglue.o): undefined reference to symbol '__res_ninit@@GLIBC_2.2.5'
          //lib/x86_64-linux-gnu/libc.so.6: error adding symbols: DSO missing from command line
          collect2: error: ld returned 1 exit status

[pnehrer]

Yes, I believe that was the error.

[benesch]

Ah, ok, it's because the musl builder isn't setting CC to musl-gcc and autoconf can't guess that it's supposed to use "musl-gcc" either. If you set CC and CXX before invoking cargo, I bet things will just work out of the box for you with the gssapi-vendored feature:

docker run ekidd/rust-musl-builder:nightly-2020-11-19 env CC=musl-gcc CXX=musl-g++ cargo build

[pnehrer]

Hmmm I now get different errors:

  = note: /usr/bin/ld: /home/rust/src/target/debug/deps/liblibgit2_sys-38ef062e5795b808.rlib(attr.o): relocation R_X86_64_32 against `.rodata.__func__.10182' can not be used when making a PIE object; recompile with -fPIC

Thank you for the fix in #24, that should work for me!

[benesch]

You bet! Just published as v0.1.13 to crates.io.

[benesch]

  = note: /usr/bin/ld: /home/rust/src/target/debug/deps/liblibgit2_sys-38ef062e5795b808.rlib(attr.o): relocation R_X86_64_32 against `.rodata.__func__.10182' can not be used when making a PIE object; recompile with -fPIC

For what it's worth, this is an issue with libgit2, it looks like, not libsasl2. libgit2 might need a stanza like this in its build script:

https://github.com/MaterializeInc/rust-krb5-src/blob/b57bf49af3f43243f761641d4dbab9cd9f19477c/build.rs#L36-L38