Marin

Just an hypothesis, may it be linked to the lack of passing the expected `--host` argument to the `./configure` script of GNU gettext? `gettext-0.21/libtextstyle/lib/Makefile.am` contains a line which explicitly states...

It seems that I can also find this in the output of `cargo`: ```rust TARGET = Some("x86_64-pc-windows-gnu") HOST = Some("x86_64-unknown-linux-gnu") ``` And that the condition that leads to using the...

It looks like this latest solution doesn't suffice, when trying this `gettext` will attempt to pass Windows tooling-specific flags disabling the odds of effective compilation. ``` libtool: error: unrecognised option:...

I got a few steps further. I removed the references to the `libtextstyle/adhoc-tests/` directory in the `libtextstyle/*` build files and then I removed a few occurrences of a ` -lc`...

Anyway my main intent when using `gettext-rs` was to internationalize a `gtk-rs`-based app, which works on Linux, I guess because the Rust binary is linked with the same `gettext` library...

> I admit I never cross-compiled anything in my life If you are willing to reproduce the concerned environment, all the commands and `cargo` flags that I used to setup...

Thank you for your answers. > Unfortunately, ./autogen.sh requires autotools and downloads files from the Internet, so I don't think it's a good idea to run it automatically on every...

>For whatever reason, opt-out is the norm for the `-sys` crates. Most libraries don't need to have a global heap context shared between the process-wide users of the library like...

>I filed #84 for this. Thanks! >Is the original problem of this issue resolved by #79? Can this be closed now? Pull request #79 addressed an issue in *dynamically linking*...

Hello, > Hi! Can you build GNU gettext itself in this environment, without using the crate? Linux-compiling the GNU Gettext package from the crate's tarball works without modification it seems....