published sass-sys@0.4.20 fails to build and link against native library

[Nemo157]

Example:

> cargo download -x sass-sys
INFO: cargo-download v0.1.2
INFO: Latest version of crate sass-sys=* is 0.4.20
INFO: Crate `sass-sys==0.4.20` downloaded successfully
INFO: Crate content extracted to ./sass-sys-0.4.20/

> cd sass-sys-0.4.20

> cargo build -vv
[...]
   Compiling sass-sys v0.4.20 (/tmp/tmp.kVOrWJwYdA/sass-sys-0.4.20)
     Running `CARGO=/home/nemo157/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/bin/cargo CARGO_MANIFEST_DIR=/tmp/tmp.kVOrWJwYdA/sass-sys-0.4.20 CARGO_PKG_AUTHORS='Marius Seritan <github@seritan.net>:Vincent Prouillet <prouillet.vincent@gmail.com>' CARGO_PKG_DESCRIPTION='Low level binding for the Sass library' CARGO_PKG_HOMEPAGE='https://github.com/compass-rs/sass-rs' CARGO_PKG_NAME=sass-sys CARGO_PKG_REPOSITORY='https://github.com/compass-rs/sass-rs.git' CARGO_PKG_VERSION=0.4.20 CARGO_PKG_VERSION_MAJOR=0 CARGO_PKG_VERSION_MINOR=4 CARGO_PKG_VERSION_PATCH=20 CARGO_PKG_VERSION_PRE= LD_LIBRARY_PATH='/tmp/tmp.kVOrWJwYdA/sass-sys-0.4.20/target/debug/deps:/home/nemo157/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib:/home/nemo157/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib' rustc --crate-name build_script_build build.rs --error-format=json --json=diagnostic-rendered-ansi --crate-type bin --emit=dep-info,link -Cembed-bitcode=no -C debuginfo=2 -C metadata=381602533f1d4ffa -C extra-filename=-381602533f1d4ffa --out-dir /tmp/tmp.kVOrWJwYdA/sass-sys-0.4.20/target/debug/build/sass-sys-381602533f1d4ffa -C incremental=/tmp/tmp.kVOrWJwYdA/sass-sys-0.4.20/target/debug/incremental -L dependency=/tmp/tmp.kVOrWJwYdA/sass-sys-0.4.20/target/debug/deps --extern num_cpus=/tmp/tmp.kVOrWJwYdA/sass-sys-0.4.20/target/debug/deps/libnum_cpus-1ad81d08984cdbab.rlib --extern pkg_config=/tmp/tmp.kVOrWJwYdA/sass-sys-0.4.20/target/debug/deps/libpkg_config-024e3ab7d35f04aa.rlib`
     Running `/tmp/tmp.kVOrWJwYdA/sass-sys-0.4.20/target/debug/build/sass-sys-381602533f1d4ffa/build-script-build`
[sass-sys 0.4.20] fatal: not a git repository (or any parent up to mount point /)
[sass-sys 0.4.20] Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).
     Running `CARGO=/home/nemo157/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/bin/cargo CARGO_MANIFEST_DIR=/tmp/tmp.kVOrWJwYdA/sass-sys-0.4.20 CARGO_PKG_AUTHORS='Marius Seritan <github@seritan.net>:Vincent Prouillet <prouillet.vincent@gmail.com>' CARGO_PKG_DESCRIPTION='Low level binding for the Sass library' CARGO_PKG_HOMEPAGE='https://github.com/compass-rs/sass-rs' CARGO_PKG_NAME=sass-sys CARGO_PKG_REPOSITORY='https://github.com/compass-rs/sass-rs.git' CARGO_PKG_VERSION=0.4.20 CARGO_PKG_VERSION_MAJOR=0 CARGO_PKG_VERSION_MINOR=4 CARGO_PKG_VERSION_PATCH=20 CARGO_PKG_VERSION_PRE= LD_LIBRARY_PATH='/tmp/tmp.kVOrWJwYdA/sass-sys-0.4.20/target/debug/deps:/home/nemo157/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib:/home/nemo157/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib' OUT_DIR=/tmp/tmp.kVOrWJwYdA/sass-sys-0.4.20/target/debug/build/sass-sys-855fe86c8e567e15/out rustc --crate-name sass_sys src/lib.rs --error-format=json --json=diagnostic-rendered-ansi --crate-type lib --emit=dep-info,metadata,link -Cembed-bitcode=no -C debuginfo=2 -C metadata=786030e66d118754 -C extra-filename=-786030e66d118754 --out-dir /tmp/tmp.kVOrWJwYdA/sass-sys-0.4.20/target/debug/deps -C incremental=/tmp/tmp.kVOrWJwYdA/sass-sys-0.4.20/target/debug/incremental -L dependency=/tmp/tmp.kVOrWJwYdA/sass-sys-0.4.20/target/debug/deps --extern libc=/tmp/tmp.kVOrWJwYdA/sass-sys-0.4.20/target/debug/deps/liblibc-168e700d4fe57208.rmeta`
    Finished dev [unoptimized + debuginfo] target(s) in 1.37s

> tree target/debug/build/sass-sys*
target/debug/build/sass-sys-381602533f1d4ffa
├── build-script-build
├── build_script_build-381602533f1d4ffa
└── build_script_build-381602533f1d4ffa.d
target/debug/build/sass-sys-855fe86c8e567e15
├── invoked.timestamp
├── out
├── output
├── root-output
└── stderr

1 directory, 7 files

The .git directory is (correctly) not published as part of the package, so the build script returns at

sass-rs/sass-sys/build.rs

Line 217 in 9674924

if !Path::new("libsass/.git").exists() {

This means there is no native library built in the OUT_DIR, and the rustc-link-{search,lib} commands are not output, so the compiler does not attempt to link against it, resulting in errors when building applications like

          /usr/bin/ld: /home/nemo157/sources/docs.rs/target/debug/deps/libsass_rs-14c2270bd1f1822c.rlib(sass_rs-14c2270bd1f1822c.sass_rs.5hp5sijh-cgu.7.rcgu.o): in function `<sass_rs::bindings::context::Context as core::ops::drop::Drop>::drop':
          /home/nemo157/.cargo/registry/src/git.colasdn.top-1ecc6299db9ec823/sass-rs-0.2.2/src/bindings/context.rs:143: undefined reference to `sass_delete_file_context'
          /usr/bin/ld: /home/nemo157/.cargo/registry/src/git.colasdn.top-1ecc6299db9ec823/sass-rs-0.2.2/src/bindings/context.rs:146: undefined reference to `sass_delete_data_context'
          collect2: error: ld returned 1 exit status

[jyn514]

Originally found in rust-lang/docs.rs#763

[Keats]

See #69

I need to add a CI that doesn't do a recursive git clone... Any idea how to fix it without causing issues for #69?

I'll yank 0.4.20 later today

[Nemo157]

I would recommend just doing the submodule update as part of the CI script, the build.rs should just assume that either it's building from a package (which has the source files embedded in it) or the developer has run git submodule update --init themselves.

EDIT: I also just checked what happens when you depend on a crate via git = ... and it has submodules, Cargo will clone those submodules for you as well.

[Keats]

cc @teknokatze

[Keats]

Crate has been yanked. I can revert to c9ebddf but that's causing issues for other people. If the requirements is to work without network it's tough though.

[Nemo157]

I'm not sure if I see the issues with c9ebddf, the only case that won't just work is when someone clones the repo and runs cargo build in it. You could add documentation to the readme mentioning that you must run git submodule update --init, and even a check in build.rs like

if !get_libsass_folder().join("Makefile").exists() {
    panic!("Could not find libsass source, try running `git submodule update --init` if you are building from the repository");
}

Crate has been yanked. I can revert to c9ebddf but that's causing issues for other people. If the requirements is to work without network it's tough though.

I mean that's the requirement for basically any system package manager.
I'd rather recommend to get libsass on a certain commit and copy that into the source of sass-sys (I mean we also have libsass packaged, would be good to reuse that, but different issue) than "just run git submodule" which just can not work.

[Nemo157]

I'd rather recommend to get libsass on a certain commit and copy that into the source of sass-sys

cargo package does that already for the packaged crate, as long as the submodule is up to date when publishing.

I'm not sure if I see the issues with c9ebddf, the only case that won't just work is when someone clones the repo and runs cargo build in it. You could add documentation to the readme mentioning that you must run git submodule update --init, and even a check in build.rs like

if !get_libsass_folder().join("Makefile").exists() {
    panic!("Could not find libsass source, try running `git submodule update --init` if you are building from the repository");
}

If you follow the tickets, you can see that our builders for pkgsrc fail to build www/zola from release as it depends on the sass-sys crate and git is not present in the sandbox (network is allowed up to some point)

I'd rather recommend to get libsass on a certain commit and copy that into the source of sass-sys

cargo package does that already for the packaged crate, as long as the submodule is up to date when publishing.

Okay, so what is the issue then, was it just a mistake how Keats did the release or with the patch in general?
I don't really care what the solution will be as long as the pkgsrc sandboxed builders can start building it again. I'm not a rust developer, so I'm just trying to understand how we can solve this.

[Nemo157]

Yes, c9ebddf is the revision at which the build.rs does not attempt to do any git operations itself, and relies on libsass having the correct content already. There are in general 3 ways in which sass-sys will be built:

1. Normal dependency off crates.io (which is presumably what pkgsrc uses). The published package includes the files inside libsass (less the unneeded .git dir) so it will have everything needed already.

2. A sass-sys = { git = "https://github.com/compass-rs/sass-rs" } dependency or patch. Cargo will implicitly perform the equivalent of a git submodule update --init for this so the files will be there.

3. Someone cloning the repo and attempting to build it locally (or as a path dependency). This is the only case in which the libsass files will not be present and you would get an error like No targets specified and no makefile found #63. IMO having to manage submodules yourself is standard for git repos that use them, so adding in a nicer error message by checking that the submodule has been updated at least once is enough.

[Keats]

Can a PR be made? I won't have time for a while.

[Keats]

0.4.21 published