alacritty 0.9.0 / v0.10.0-dev fails to compile on OpenBSD 6.9-current

[1dotd4]

After installing as written in the INSTALL.md, and running cargo build --release at last step of compilation it fails to compile the program. At first glance it looks like missing something in the build.rs but I'm not a Rust expert to say this.

The same happens with cargo install alacritty.

System

OS: OpenBSD 6.9-current
Version: failed to compile alacritty v0.9.0 / alacritty v0.10.0-dev the error is the same
Linux/BSD: Xenocara, i3

Logs

Building [=======================> ] 188/189: alacritty(bin)

error: linking with `cc` failed: exit status: 1
  |
  = note: [annoying stuff]
  = note: ld: error: unable to find library -lxkbcommon
          cc: error: linker command failed with exit code 1 (use -v to see invocation)

error: aborting due to previous error

error: could not compile `alacritty`

To learn more, run the command again with --verbose.

But I have libxkbcommon:

$ pkg_info -Q libxkbcommon
debug-libxkbcommon-1.3.0
libxkbcommon-1.3.0 (installed)

So I think I should probably say somewhere to get also the /usr/local/lib/, but this looks awkward as it could have failed somewhere else.

Solution

While this get fixed, RUSTFLAGS='-L/usr/local/lib' cargo build --release.

In alacritty/build.rs, in the main function add the following:

• check for target "openbsd"
• add println!(r"cargo:rustc-link-search=/usr/local/lib")

[1dotd4]

I've created #5423 hope that's fine.

[chrisduerr]

Do you have any arguments why this should be added to Alacritty as a permanent thing? Either documentation or build.rs? Otherwise I'd advocate for leaving it up to OpenBSD users to figure out how to make compilers work with their operating system.

[1dotd4]

• I'll look around and ask if this can be fixed by the maintainer of lang/rust in OpenBSD:
  • then this is no longer an issue.
• Otherwise I'll just point out the RUSTFLAGS in the INSTALL.md.

[1dotd4]

I've found this stackoverflow question with nice answers which explain the different ways this can be solved without the maintainer changing cargo the build or modifying the code here.

Some of this can be specified in ~/.cargo/config.toml it's expecially pretty this one.

[build]
rustflags = ["-L","/usr/local/lib"]

I'm now waiting for a reply by the rust/lang maintainer as I wish that cargo and alacritty (or any other future rust project) work out of the box in OpenBSD without looking for this hack.

[semarie]

Answering as OpenBSD lang/rust maintainer.

The problem is related to smithay-client-toolkit crate, which tries to link with xkbcommon assuming the library is present in default libraries path of the compiler/linker, which is wrong on several systems (OpenBSD as found here, but also NetBSD, maybe some others systems, but I don't have checked futher).

Any programs using this crate on OpenBSD (or NetBSD) will have the same problem. The right solution would be smithay-client-toolkit crate to use proper build.rs script to detect at build time the library path using pkg-config or permit user to configure the path (with environment variable, which is common for Rust crates). An issue should be opened on it.

Regarding the workaround, passing -L /usr/local/lib affects the whole build process and could potentially have unwanted effects: some system libraries (in /usr/lib) could conflict in subtile manner with ones in /usr/local/lib). It will depend of installed libraries on the machine used to build the program. In a standard system (with only third party libraries installed from ports), I am only aware of libLLVM.so library which could lead to such problems.

[chrisduerr]

Thanks for looking into this and sending a PR @semarie. This should get resolved upstream relatively quickly together with a patch release. At that point the propagation of the dependency will hopefully take care of the problem by itself over time.