Koka / gettext-rs

GNU Gettext FFI binding for Rust
51 stars 25 forks source link

Cannot build gettext-sys #73

Closed mks-h closed 2 years ago

mks-h commented 2 years ago

When I'm building gettext-rs crate using dev profile — it seems to skip building gettext-sys. But when I'm building it with a release profile — it starts building gettext-sys for around 5 minutes and then errors out. The same happens if I build gettext-sys with dev profile. You can see gist with the full log. I'm on openSUSE Tumbleweed, and I do have gettext-devel and gcc packages installed. Thanks in advance!

Compiling gettext-sys v0.21.1 (/home/maksym/Projects/gettext-rs/gettext-sys)
error: failed to run custom build command for `gettext-sys v0.21.1 (/home/maksym/Projects/gettext-rs/gettext-sys)`

Caused by:
  process didn't exit successfully: `/home/maksym/Projects/gettext-rs/target/release/build/gettext-sys-2600aa0bcb629547/build-script-build` (exit status: 101)
  --- stdout
  cargo:rerun-if-env-changed=X86_64_UNKNOWN_LINUX_GNU_GETTEXT_SYSTEM
  cargo:rerun-if-env-changed=GETTEXT_SYSTEM
  /usr/bin/cmp
  /usr/bin/diff
  /usr/bin/find
  /usr/bin/xz
  cargo:rerun-if-env-changed=X86_64_UNKNOWN_LINUX_GNU_GETTEXT_DIR
  cargo:rerun-if-env-changed=GETTEXT_DIR
  cargo:rerun-if-env-changed=X86_64_UNKNOWN_LINUX_GNU_GETTEXT_BIN_DIR
  cargo:rerun-if-env-changed=GETTEXT_BIN_DIR
  cargo:rerun-if-env-changed=X86_64_UNKNOWN_LINUX_GNU_GETTEXT_LIB_DIR
  cargo:rerun-if-env-changed=GETTEXT_LIB_DIR
  cargo:rerun-if-env-changed=X86_64_UNKNOWN_LINUX_GNU_GETTEXT_INCLUDE_DIR
  cargo:rerun-if-env-changed=GETTEXT_INCLUDE_DIR
  OPT_LEVEL = Some("3")
  TARGET = Some("x86_64-unknown-linux-gnu")
  HOST = Some("x86_64-unknown-linux-gnu")
  CC_x86_64-unknown-linux-gnu = None
  CC_x86_64_unknown_linux_gnu = None
  HOST_CC = None
  CC = None
  CFLAGS_x86_64-unknown-linux-gnu = None
  CFLAGS_x86_64_unknown_linux_gnu = None
  HOST_CFLAGS = None
  CFLAGS = None
  CRATE_CC_NO_DEFAULTS = None
  DEBUG = Some("false")
  CARGO_CFG_TARGET_FEATURE = Some("fxsr,sse,sse2")
  running: "tar" "xJf" "/home/maksym/Projects/gettext-rs/gettext-sys/gettext-0.21.tar.xz" "--strip-components" "1"
  running: "sh" "/tmp/t6326-0/gettext/configure" "--without-emacs" "--disable-java" "--disable-csharp" "--disable-c++" "--disable-shared" "--enable-static" "--enable-fast-install" "--with-included-gettext" "--with-included-glib" "--with-included-libcroco" "--with-included-libunistring" "--prefix=/tmp/t6326-0"
Minoru commented 2 years ago

Aha! So the library is being built in /tmp/t6326-0/lib64 (the log is full of mentions of that directory), but we're trying to copy from /tmp/t6326-0/lib. This is definitely a problem with our build.rs.

Now the question is: why does gettex is trying to place the lib into "lib64" rather than "lib".

Minoru commented 2 years ago

@delight-aug, can you please try this patch and see if it helps?

diff --git a/gettext-sys/build.rs b/gettext-sys/build.rs
index 37d543b..153108a 100644
--- a/gettext-sys/build.rs
+++ b/gettext-sys/build.rs
@@ -220,6 +220,7 @@ fn main() {
     }

     cmd.arg(format!("--prefix={}", &posix_path(&build_dir)));
+    cmd.arg(format!("--libdir={}", &posix_path(&build_dir.join("lib"))));

     if target != host && (!target.contains("windows") || !host.contains("windows")) {
         // NOTE GNU terminology

(I don't know why it chooses lib64 over lib, so I'm just forcing it to use lib. It's not a big deal since we are not actually installing anything on the user's machine — these paths are only relevant to our own build.rs, which copies the necessary files and statically links them with the final executable.)

mks-h commented 2 years ago

It's choosing lib64 because, turns out, there is openSuse's downstream patch, that changes path. You can see this page for used sources/patches.

Minoru commented 2 years ago

gettext-sys doesn't rely on the system package, and compiles its own from the source it bundles. So downstream patches shouldn't affect anything.

mks-h commented 2 years ago

The patch worked!

Minoru commented 2 years ago

Thanks for testing!