Alacritty: no method named `set_urgent` found for type `window::Window` in the current scope

Created on 10 Jul 2019  ·  84Comments  ·  Source: alacritty/alacritty

Which operating system does the issue occur on?

  • NetBSD 8.99.48 NetBSD 8.99.48 (GENERIC) amd64
  • Using X11 from base

While running cargo build in the checkout at commit 84aca672964e29b5b4503b7da7bc34fc395f08ab, I get this error:

   Compiling copypasta v0.6.0 (/home/ng0/code/re-src/rust_crates/alacritty/copypasta)
error[E0599]: no method named `set_urgent` found for type `window::Window` in the current scope
   --> alacritty_terminal/src/display.rs:493:29
    |
493 |                 self.window.set_urgent(is_urgent);
    |                             ^^^^^^^^^^
    | 
   ::: alacritty_terminal/src/window.rs:59:1
    |
59  | pub struct Window {
    | ----------------- method `set_urgent` not found for this
    |
    = help: items from traits can only be used if the trait is implemented and in scope
    = note: the following trait defines an item `set_urgent`, perhaps you need to implement it:
            candidate #1: `winit::os::unix::WindowExt`

error: aborting due to previous error

For more information about this error, try `rustc --explain E0599`.
error: Could not compile `alacritty_terminal`.

To learn more, run the command again with --verbose.
B - build failure C - waiting on author H - bsd
Source
picture teknokatze

Most helpful comment

I have to apply a patch for the xcb crate first, mainly to change the wrong hardcoded python name. Without this the build fails here.

Rather than trying to work around this, I'm sure upstream would really appreciate a patch if it is simple and improves cross-platform support.

Yes, pkgsrc policy is not to keep patches, and everything but this https://github.com/rtbo/rust-xcb/issues/62 is upstream, so it's just a matter of waiting.

Moving on I need to pass on a bunch of environment variables down to cargo.

It should be possible just to specify these while running cargo, right?

Don't get me wrong, I am completely fine with you using pkgsrc. I'm just trying to figure out a way to approach this problem in more simple and straight forward steps rather than trying to climb a massive wall by running at it repeatedly.

It's not that easy. I can see how far I get, but for me this approach is the one which is the massive wall given how much I learned about what still needs to be done in cargo itself to be properly integrated with systems (passing variables through was just the beginning of a really interesting learning experience of what's not possible today or really hard). In any case, I will get back to you as soon as I have results.

picture teknokatze on 25 Aug 2019
👍2

All 84 comments

What I'm interested in, is what might have caused this, anything familiar to you?

My money is onX11 not being in the path, which I can look into in the next couple of days.

Verbose build output:

   Compiling alacritty_terminal v0.3.3 (/home/ng0/code/re-src/rust_crates/alacritty/alacritty_terminal)
     Running `rustc --edition=2018 --crate-name alacritty_terminal alacritty_terminal/src/lib.rs --color always --crate-type lib --emit=dep-info,metadata,link -C debuginfo=2 --cfg 'feature="default"' -C metadata=b5424ed74b435f34 -C extra-filename=-b5424ed74b435f34 --out-dir /home/ng0/code/re-src/rust_crates/alacritty/target/debug/deps -C incremental=/home/ng0/code/re-src/rust_crates/alacritty/target/debug/incremental -L dependency=/home/ng0/code/re-src/rust_crates/alacritty/target/debug/deps --extern base64=/home/ng0/code/re-src/rust_crates/alacritty/target/debug/deps/libbase64-cd2efa59f9a2bf49.rlib --extern bitflags=/home/ng0/code/re-src/rust_crates/alacritty/target/debug/deps/libbitflags-2223df8e57e92af9.rlib --extern copypasta=/home/ng0/code/re-src/rust_crates/alacritty/target/debug/deps/libcopypasta-eb078eba91633a52.rlib --extern crossbeam_channel=/home/ng0/code/re-src/rust_crates/alacritty/target/debug/deps/libcrossbeam_channel-1eb380f81888d9f7.rlib --extern errno=/home/ng0/code/re-src/rust_crates/alacritty/target/debug/deps/liberrno-ea576f14a973e3fa.rlib --extern fnv=/home/ng0/code/re-src/rust_crates/alacritty/target/debug/deps/libfnv-3405767909004067.rlib --extern font=/home/ng0/code/re-src/rust_crates/alacritty/target/debug/deps/libfont-52f765def8269a0a.rlib --extern glutin=/home/ng0/code/re-src/rust_crates/alacritty/target/debug/deps/libglutin-94529c756d42b701.rlib --extern image=/home/ng0/code/re-src/rust_crates/alacritty/target/debug/deps/libimage-3c3d1e0a13559352.rlib --extern libc=/home/ng0/code/re-src/rust_crates/alacritty/target/debug/deps/liblibc-2ff902f236e60402.rlib --extern log=/home/ng0/code/re-src/rust_crates/alacritty/target/debug/deps/liblog-12843f27dd4758e9.rlib --extern mio=/home/ng0/code/re-src/rust_crates/alacritty/target/debug/deps/libmio-3f0087697804a2be.rlib --extern mio_extras=/home/ng0/code/re-src/rust_crates/alacritty/target/debug/deps/libmio_extras-b7ab99de6ea73ca8.rlib --extern nix=/home/ng0/code/re-src/rust_crates/alacritty/target/debug/deps/libnix-44243aa6ce8e235a.rlib --extern notify=/home/ng0/code/re-src/rust_crates/alacritty/target/debug/deps/libnotify-62f1d0652079bf3a.rlib --extern parking_lot=/home/ng0/code/re-src/rust_crates/alacritty/target/debug/deps/libparking_lot-edd0e2bf4f4733ec.rlib --extern serde=/home/ng0/code/re-src/rust_crates/alacritty/target/debug/deps/libserde-ba65de81ee755563.rlib --extern serde_derive=/home/ng0/code/re-src/rust_crates/alacritty/target/debug/deps/libserde_derive-31a404177c5a492b.so --extern serde_yaml=/home/ng0/code/re-src/rust_crates/alacritty/target/debug/deps/libserde_yaml-1a55c4e004da6229.rlib --extern signal_hook=/home/ng0/code/re-src/rust_crates/alacritty/target/debug/deps/libsignal_hook-312ba6c79f47953f.rlib --extern static_assertions=/home/ng0/code/re-src/rust_crates/alacritty/target/debug/deps/libstatic_assertions-69802d4ace39c161.rlib --extern terminfo=/home/ng0/code/re-src/rust_crates/alacritty/target/debug/deps/libterminfo-a4e948d775622c14.rlib --extern unicode_width=/home/ng0/code/re-src/rust_crates/alacritty/target/debug/deps/libunicode_width-bb18d599fc306dc4.rlib --extern url=/home/ng0/code/re-src/rust_crates/alacritty/target/debug/deps/liburl-71fff3c80ee1a351.rlib --extern vte=/home/ng0/code/re-src/rust_crates/alacritty/target/debug/deps/libvte-26f9e8d6db64f4a6.rlib -L native=/home/ng0/code/re-src/rust_crates/alacritty/target/debug/build/libloading-95b135c413132085/out -L native=/usr/pkg/lib -L native=/usr/lib -L native=/usr/pkg/lib`
error[E0599]: no method named `set_urgent` found for type `window::Window` in the current scope
   --> alacritty_terminal/src/display.rs:493:29
    |
493 |                 self.window.set_urgent(is_urgent);
    |                             ^^^^^^^^^^
    | 
   ::: alacritty_terminal/src/window.rs:59:1
    |
59  | pub struct Window {
    | ----------------- method `set_urgent` not found for this
    |
    = help: items from traits can only be used if the trait is implemented and in scope    = note: the following trait defines an item `set_urgent`, perhaps you need to implement it:
            candidate #1: `winit::os::unix::WindowExt`

error: aborting due to previous error

For more information about this error, try `rustc --explain E0599`.
error: Could not compile `alacritty_terminal`.

Caused by:
  process didn't exit successfully: `rustc --edition=2018 --crate-name alacritty_terminal alacritty_terminal/src/lib.rs --color always --crate-type lib --emit=dep-info,metadata,link -C debuginfo=2 --cfg 'feature="default"' -C metadata=b5424ed74b435f34 -C extra-filename=-b5424ed74b435f34 --out-dir /home/ng0/code/re-src/rust_crates/alacritty/target/debug/deps -C incremental=/home/ng0/code/re-src/rust_crates/alacritty/target/debug/incremental -L dependency=/home/ng0/code/re-src/rust_crates/alacritty/target/debug/deps --extern base64=/home/ng0/code/re-src/rust_crates/alacritty/target/debug/deps/libbase64-cd2efa59f9a2bf49.rlib --extern bitflags=/home/ng0/code/re-src/rust_crates/alacritty/target/debug/deps/libbitflags-2223df8e57e92af9.rlib --extern copypasta=/home/ng0/code/re-src/rust_crates/alacritty/target/debug/deps/libcopypasta-eb078eba91633a52.rlib --extern crossbeam_channel=/home/ng0/code/re-src/rust_crates/alacritty/target/debug/deps/libcrossbeam_channel-1eb380f81888d9f7.rlib --extern errno=/home/ng0/code/re-src/rust_crates/alacritty/target/debug/deps/liberrno-ea576f14a973e3fa.rlib --extern fnv=/home/ng0/code/re-src/rust_crates/alacritty/target/debug/deps/libfnv-3405767909004067.rlib --extern font=/home/ng0/code/re-src/rust_crates/alacritty/target/debug/deps/libfont-52f765def8269a0a.rlib --extern glutin=/home/ng0/code/re-src/rust_crates/alacritty/target/debug/deps/libglutin-94529c756d42b701.rlib --extern image=/home/ng0/code/re-src/rust_crates/alacritty/target/debug/deps/libimage-3c3d1e0a13559352.rlib --extern libc=/home/ng0/code/re-src/rust_crates/alacritty/target/debug/deps/liblibc-2ff902f236e60402.rlib --extern log=/home/ng0/code/re-src/rust_crates/alacritty/target/debug/deps/liblog-12843f27dd4758e9.rlib --extern mio=/home/ng0/code/re-src/rust_crates/alacritty/target/debug/deps/libmio-3f0087697804a2be.rlib --extern mio_extras=/home/ng0/code/re-src/rust_crates/alacritty/target/debug/deps/libmio_extras-b7ab99de6ea73ca8.rlib --extern nix=/home/ng0/code/re-src/rust_crates/alacritty/target/debug/deps/libnix-44243aa6ce8e235a.rlib --extern notify=/home/ng0/code/re-src/rust_crates/alacritty/target/debug/deps/libnotify-62f1d0652079bf3a.rlib --extern parking_lot=/home/ng0/code/re-src/rust_crates/alacritty/target/debug/deps/libparking_lot-edd0e2bf4f4733ec.rlib --extern serde=/home/ng0/code/re-src/rust_crates/alacritty/target/debug/deps/libserde-ba65de81ee755563.rlib --extern serde_derive=/home/ng0/code/re-src/rust_crates/alacritty/target/debug/deps/libserde_derive-31a404177c5a492b.so --extern serde_yaml=/home/ng0/code/re-src/rust_crates/alacritty/target/debug/deps/libserde_yaml-1a55c4e004da6229.rlib --extern signal_hook=/home/ng0/code/re-src/rust_crates/alacritty/target/debug/deps/libsignal_hook-312ba6c79f47953f.rlib --extern static_assertions=/home/ng0/code/re-src/rust_crates/alacritty/target/debug/deps/libstatic_assertions-69802d4ace39c161.rlib --extern terminfo=/home/ng0/code/re-src/rust_crates/alacritty/target/debug/deps/libterminfo-a4e948d775622c14.rlib --extern unicode_width=/home/ng0/code/re-src/rust_crates/alacritty/target/debug/deps/libunicode_width-bb18d599fc306dc4.rlib --extern url=/home/ng0/code/re-src/rust_crates/alacritty/target/debug/deps/liburl-71fff3c80ee1a351.rlib --extern vte=/home/ng0/code/re-src/rust_crates/alacritty/target/debug/deps/libvte-26f9e8d6db64f4a6.rlib -L native=/home/ng0/code/re-src/rust_crates/alacritty/target/debug/build/libloading-95b135c413132085/out -L native=/usr/pkg/lib -L native=/usr/lib -L native=/usr/pkg/lib` (exit code: 1)

I will eventually package this for pkgsrc, this was just my initial in-source test.

teknokatze picture teknokatze on 10 Jul 2019

Attempted to fix this in https://github.com/jwilm/alacritty/pull/2633, however I do not have any system to test it. Can you confirm if this works or not?

chrisduerr picture chrisduerr on 10 Jul 2019

Okay, will do so tomorrow morning.

It certainly looks more portable now wrt the platforms pkgsrc targets, as it is easier to assume that packagers fix platform specific problems rather than writing in a supported range like it is common in some places. I have to catch some sleep before apply this patch.

teknokatze picture teknokatze on 10 Jul 2019
👍1

Okay, I have tested this and I get the same results as the travis CI run of the PR gets:

   Compiling copypasta v0.6.0 (/home/ng0/code/re-src/rust_crates/alacritty/copypasta)
error[E0433]: failed to resolve: use of undeclared type or module `x11_dl`
   --> alacritty_terminal/src/window.rs:428:13
    |
428 |         use x11_dl::xlib::{self, PropModeReplace, XA_CARDINAL};
    |             ^^^^^^ use of undeclared type or module `x11_dl`

error[E0432]: unresolved import `x11_dl`
   --> alacritty_terminal/src/window.rs:428:13
    |
428 |         use x11_dl::xlib::{self, PropModeReplace, XA_CARDINAL};
    |             ^^^^^^ use of undeclared type or module `x11_dl`

error[E0425]: cannot find value `XA_CARDINAL` in this scope
   --> alacritty_terminal/src/window.rs:446:21
    |
446 |                     XA_CARDINAL,
    |                     ^^^^^^^^^^^ not found in this scope

error[E0425]: cannot find value `PropModeReplace` in this scope
   --> alacritty_terminal/src/window.rs:448:21
    |
448 |                     PropModeReplace,
    |                     ^^^^^^^^^^^^^^^ not found in this scope

warning: unused imports: `PropModeReplace`, `XA_CARDINAL`
   --> alacritty_terminal/src/window.rs:428:34
    |
428 |         use x11_dl::xlib::{self, PropModeReplace, XA_CARDINAL};
    |                                  ^^^^^^^^^^^^^^^  ^^^^^^^^^^^
    |
    = note: #[warn(unused_imports)] on by default

error[E0119]: conflicting implementations of trait `window::OsExtensions` for type `window::Window`:
   --> alacritty_terminal/src/window.rs:423:1
    |
420 | impl OsExtensions for Window {}
    | ---------------------------- first implementation here
...
423 | impl OsExtensions for Window {
    | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ conflicting implementation for `window::Window`

error: aborting due to 5 previous errors

Some errors have detailed explanations: E0119, E0425, E0432, E0433.
For more information about an error, try `rustc --explain E0119`.
error: Could not compile `alacritty_terminal`.

To learn more, run the command again with --verbose.
teknokatze picture teknokatze on 10 Jul 2019

Correction: It's not the same.

rror[E0119]: conflicting implementations of trait `window::OsExtensions` for type `window::Window`:
   --> alacritty_terminal/src/window.rs:423:1
    |
420 | impl OsExtensions for Window {}
    | ---------------------------- first implementation here
...
423 | impl OsExtensions for Window {
    | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ conflicting implementation for `window::Window`
error[E0119]: conflicting implementations of trait `window::OsExtensions` for type `window::Window`:
   --> alacritty_terminal/src/window.rs:423:1
    |
420 | impl OsExtensions for Window {}
    | ---------------------------- first implementation here
...
423 | impl OsExtensions for Window {
    | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ conflicting implementation for `window::Window`
error: aborting due to previous error
For more information about this error, try `rustc --explain E0119`.
error: Could not compile `alacritty_terminal`.
warning: build failed, waiting for other jobs to finish...
error: aborting due to previous error
For more information about this error, try `rustc --explain E0119`.
error: Could not compile `alacritty_terminal`.
To learn more, run the command again with --verbose.
The command "ci/script.sh" exited with 101.
Done. Your build exited with 1.
teknokatze picture teknokatze on 10 Jul 2019

If you want to set up a NetBSD builder with pkgsrc + pkgsrc-wip, this is now in wip/alacritty, which required some patches (not to alacritty itself) and results in the same errors as outside of pkgsrc so far.

teknokatze picture teknokatze on 10 Jul 2019

I'm not sure about setting up a NetBSD system at this point, though I think Alacritty itself should build now (I've updated the PR again). If no dependencies are messing things up, we could be good to go now.

chrisduerr picture chrisduerr on 10 Jul 2019

Thanks, I'll test it once you have pushed the PR update.

What is messing up is one of the dependency deep in your graph, xcb. I'm not sure if the maintainer is on hiatus? Tickets have been added since February 2018. My issue with it can be worked around easily though, by patching the hardcoded assumed binary name for python3.

Maybe you have an idea about the state of it? I'm just getting started with writing more Rust, wouldn't really feel comfortable with adopting it.

teknokatze picture teknokatze on 10 Jul 2019

Thanks, I'll test it once you have pushed the PR update.

Oops, looks like I forgot to push it, thanks. Should be good now.

What is messing up is one of the dependency deep in your graph, xcb

Where did you get that from? So far, none of the errors you've posted were related to an xcb library at all.

chrisduerr picture chrisduerr on 10 Jul 2019

Where did you get that from? So far, none of the errors you've posted were related to an xcb library at all.

Ah, sorry this is unrelated to this error, I took your statement too lose.

teknokatze picture teknokatze on 10 Jul 2019

1 error down, 4 more to inspect on my side.

Could it be that some part of X11 needs to be part of the build environment which I overlooked, and this is throwing the errors?

   Compiling glutin v0.21.0
error[E0433]: failed to resolve: use of undeclared type or module `x11_dl`
   --> alacritty_terminal/src/window.rs:428:13
    |
428 |         use x11_dl::xlib::{self, PropModeReplace, XA_CARDINAL};
    |             ^^^^^^ use of undeclared type or module `x11_dl`

error[E0432]: unresolved import `x11_dl`
   --> alacritty_terminal/src/window.rs:428:13
    |
428 |         use x11_dl::xlib::{self, PropModeReplace, XA_CARDINAL};
    |             ^^^^^^ use of undeclared type or module `x11_dl`

error[E0425]: cannot find value `XA_CARDINAL` in this scope
   --> alacritty_terminal/src/window.rs:446:21
    |
446 |                     XA_CARDINAL,
    |                     ^^^^^^^^^^^ not found in this scope

error[E0425]: cannot find value `PropModeReplace` in this scope
   --> alacritty_terminal/src/window.rs:448:21
    |
448 |                     PropModeReplace,
    |                     ^^^^^^^^^^^^^^^ not found in this scope

warning: unused imports: `PropModeReplace`, `XA_CARDINAL`
   --> alacritty_terminal/src/window.rs:428:34
    |
428 |         use x11_dl::xlib::{self, PropModeReplace, XA_CARDINAL};
    |                                  ^^^^^^^^^^^^^^^  ^^^^^^^^^^^
    |
    = note: #[warn(unused_imports)] on by default

error: aborting due to 4 previous errors

Some errors have detailed explanations: E0425, E0432, E0433.
For more information about an error, try `rustc --explain E0425`.
error: Could not compile `alacritty_terminal`.

To learn more, run the command again with --verbose.
*** Error code 101
teknokatze picture teknokatze on 10 Jul 2019

Could it be that some part of X11 needs to be part of the build environment which I overlooked, and this is throwing the errors?

Yes. You'll need libxcb-devel or whatever it's called in NetBSD to be able to compile Alacritty. Looking at Debian/Ubuntu build depedencies might give some insights into what is required:
https://github.com/jwilm/alacritty/blob/master/INSTALL.md#debianubuntu

chrisduerr picture chrisduerr on 10 Jul 2019

Okay, I'm looking into it.

As the initial error is gone, at least in my build, should this ticket be closed once the builders turn out okay?

teknokatze picture teknokatze on 10 Jul 2019

@ng-0 I'd wait until you figure out how to build it. If you can confirm it works, then I think we should be good to go.

Until now, there were only people testing on FreeBSD/OpenBSD as far as I know. So it's good to have some eyes on it from NetBSD too. Since the BSDs are a bit more different than just linux distros, they mostly all need explicit-ish support.

chrisduerr picture chrisduerr on 10 Jul 2019

Okay, agreed.

teknokatze picture teknokatze on 10 Jul 2019
❤1

@ng-0 Were you able to get this to work? If you are still having troubles I might be able to help out if you can provide the errors you're running into. I'd like to get it confirmed so the PR can be merged safely.

chrisduerr picture chrisduerr on 12 Jul 2019

I haven't been able to look into the right fix so far. If you have any clue, that would be most helpful. Otherwise I'll just move this to pkgsrc-tech@

teknokatze picture teknokatze on 13 Jul 2019

My bad, I didn't even look at the error properly. This clearly was another issue with us only specifying a depedency for Linux/FreeBSD/OpenBSD. Now it should be properly specified as not macOS or Windows.

Let me know if that does it for you. I've updated the PR.

chrisduerr picture chrisduerr on 13 Jul 2019

Oops. Too obvious.

teknokatze picture teknokatze on 13 Jul 2019

@chrisduerr you also need to update the Cargo.lock file, which isn't done in the 2nd patch

teknokatze picture teknokatze on 13 Jul 2019

Oh, thanks for catching that. But a simple cargo update should fix that. Are you able to build Alacritty now?

For x11-dl the lockfile shouldn't matter though, since it is the same on all platforms.

chrisduerr picture chrisduerr on 13 Jul 2019

Oh, I'm building in pkgsrc, as that's what I'm targeting.
Since this uses --frozen, this happens without the Cargo.lock update:

Patching file ../vendor/xcb-0.8.2/rs_client.py using Plan A...
Hunk #1 succeeded at 1.
done
===> Creating toolchain wrappers for alacritty-84aca672964e29b5b4503b7da7bc34fc395f08ab
===> Configuring for alacritty-84aca672964e29b5b4503b7da7bc34fc395f08ab
=> Checking for portability problems in extracted files
===> Building for alacritty-84aca672964e29b5b4503b7da7bc34fc395f08ab
cd /usr/work/wip/alacritty/work/alacritty-84aca672964e29b5b4503b7da7bc34fc395f08ab && /usr/bin/env OPENSSL_DIR=/usr USETOOLS=no PTHREAD_CFLAGS=\ -pthread\  PTHREAD_LDFLAGS=\ -pthread PTHREAD_LIBS= PTHREADBASE=/usr DL_CFLAGS=\ -pthread\  DL_LDFLAGS=\ -pthread DL_LIBS= PYTHON=/usr/pkg/bin/python3.7 CC=clang CFLAGS=-O2\ -I/usr/pkg/include\ -I/usr/include\ -I/usr/pkg/include/python3.7\ -I/usr/X11R7/include/freetype2\ -I/usr/X11R7/include CPPFLAGS=-I/usr/pkg/include\ -I/usr/include\ -I/usr/pkg/include/python3.7\ -I/usr/X11R7/include/freetype2\ -I/usr/X11R7/include CXX=clang++ CXXFLAGS=-O2\ -I/usr/pkg/include\ -I/usr/include\ -I/usr/pkg/include/python3.7\ -I/usr/X11R7/include/freetype2\ -I/usr/X11R7/include COMPILER_RPATH_FLAG=-Wl,-R F77=false FC=false FFLAGS=-O LANG=C LC_ALL=C LC_COLLATE=C LC_CTYPE=C LC_MESSAGES=C LC_MONETARY=C LC_NUMERIC=C LC_TIME=C LDFLAGS=-L/usr/pkg/lib\ -L/usr/lib\ -Wl,-R/usr/lib\ -L/usr/X11R7/lib\ -Wl,-R/usr/X11R7/lib\ -Wl,-R/usr/pkg/lib LINKER_RPATH_FLAG=-R PATH=/usr/work/wip/alacritty/work/.cwrapper/bin:/usr/work/wip/alacritty/work/.buildlink/bin:/usr/work/wip/alacritty/work/.tools/bin:/usr/pkg/bin:/home/ng0/bin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/X11R7/bin:/usr/pkg/bin:/usr/pkg/sbin:/usr/games:/usr/local/bin:/usr/local/sbin:/home/ng0/code/dev/prefix/bin:/home/ng0/code/dev/prefix/bin:/usr/pkg/bin:/usr/X11R7/bin PREFIX=/usr/pkg MAKELEVEL=0 CONFIG_SITE= PKG_SYSCONFDIR=/usr/pkg/etc HOME=/usr/work/wip/alacritty/work/.home CWRAPPERS_CONFIG_DIR=/usr/work/wip/alacritty/work/.cwrapper/config CPP=clang-cpp LOCALBASE=/usr/pkg X11BASE=/usr/X11R7 PKGMANDIR=man PKGINFODIR=info PKGGNUDIR=gnu/ MAKECONF=/dev/null OBJECT_FMT=ELF USETOOLS=no BSD_INSTALL_PROGRAM=/usr/bin/install\ -c\ -s\ -o\ ng0\ -g\ users\ -m\ 755 BSD_INSTALL_SCRIPT=/usr/bin/install\ -c\ -o\ ng0\ -g\ users\ -m\ 755 BSD_INSTALL_LIB=/usr/bin/install\ -c\ -o\ ng0\ -g\ users\ -m\ 755 BSD_INSTALL_DATA=/usr/bin/install\ -c\ -o\ ng0\ -g\ users\ -m\ 644 BSD_INSTALL_MAN=/usr/bin/install\ -c\ -o\ ng0\ -g\ users\ -m\ 644 BSD_INSTALL=/usr/bin/install BSD_INSTALL_PROGRAM_DIR=/usr/bin/install\ -d\ -o\ ng0\ -g\ users\ -m\ 755 BSD_INSTALL_SCRIPT_DIR=/usr/bin/install\ -d\ -o\ ng0\ -g\ users\ -m\ 755 BSD_INSTALL_LIB_DIR=/usr/bin/install\ -d\ -o\ ng0\ -g\ users\ -m\ 755 BSD_INSTALL_DATA_DIR=/usr/bin/install\ -d\ -o\ ng0\ -g\ users\ -m\ 755 BSD_INSTALL_MAN_DIR=/usr/bin/install\ -d\ -o\ ng0\ -g\ users\ -m\ 755 BSD_INSTALL_GAME=/usr/bin/install\ -c\ -s\ -o\ ng0\ -g\ users\ -m\ 2555 BSD_INSTALL_GAME_DATA=/usr/bin/install\ -c\ -o\ ng0\ -g\ users\ -m\ 664 BSD_INSTALL_GAME_DIR=/usr/bin/install\ -d\ -o\ ng0\ -g\ users\ -m\ 775 INSTALL_INFO= MAKEINFO=/usr/work/wip/alacritty/work/.tools/bin/makeinfo FLEX= BISON= PKG_CONFIG=/usr/work/wip/alacritty/work/.tools/bin/pkg-config PKG_CONFIG_LIBDIR=/usr/work/wip/alacritty/work/.buildlink/lib/pkgconfig:/usr/work/wip/alacritty/work/.buildlink/share/pkgconfig PKG_CONFIG_LOG=/usr/work/wip/alacritty/work/.pkg-config.log PKG_CONFIG_PATH= CWRAPPERS_CONFIG_DIR=/usr/work/wip/alacritty/work/.cwrapper/config /usr/pkg/bin/cargo build --locked --frozen --release
warning: /usr/work/wip/alacritty/work/alacritty-84aca672964e29b5b4503b7da7bc34fc395f08ab/alacritty_terminal/Cargo.toml: unused manifest key: target.cfg(not(any(target_os = "macos", windows))).depedencies
error: the lock file /usr/work/wip/alacritty/work/alacritty-84aca672964e29b5b4503b7da7bc34fc395f08ab/Cargo.lock needs to be updated but --frozen was passed to prevent this
*** Error code 101

Stop.
make[1]: stopped in /usr/pkgsrc/wip/alacritty
*** Error code 1

Stop.
make: stopped in /usr/pkgsrc/wip/alacritty
teknokatze picture teknokatze on 13 Jul 2019

I'm pretty sure this is not the fix (the fact that I run this in pkgsrc directly is simply for easy reproducibility and because I know that the failure was reproducible regardless of environment.
Can we be sure that this is because of alacritty and not a dependency? I'm still getting started with Rust.
Thanks for your patience!

error[E0433]: failed to resolve: use of undeclared type or module `x11_dl`
   --> alacritty_terminal/src/window.rs:428:13
    |
428 |         use x11_dl::xlib::{self, PropModeReplace, XA_CARDINAL};
    |             ^^^^^^ use of undeclared type or module `x11_dl`

error[E0432]: unresolved import `x11_dl`
   --> alacritty_terminal/src/window.rs:428:13
    |
428 |         use x11_dl::xlib::{self, PropModeReplace, XA_CARDINAL};
    |             ^^^^^^ use of undeclared type or module `x11_dl`

error[E0425]: cannot find value `XA_CARDINAL` in this scope
   --> alacritty_terminal/src/window.rs:446:21
    |
446 |                     XA_CARDINAL,
    |                     ^^^^^^^^^^^ not found in this scope

error[E0425]: cannot find value `PropModeReplace` in this scope
   --> alacritty_terminal/src/window.rs:448:21
    |
448 |                     PropModeReplace,
    |                     ^^^^^^^^^^^^^^^ not found in this scope

warning: unused imports: `PropModeReplace`, `XA_CARDINAL`
   --> alacritty_terminal/src/window.rs:428:34
    |
428 |         use x11_dl::xlib::{self, PropModeReplace, XA_CARDINAL};
    |                                  ^^^^^^^^^^^^^^^  ^^^^^^^^^^^
    |
    = note: #[warn(unused_imports)] on by default

error: aborting due to 4 previous errors

Some errors have detailed explanations: E0425, E0432, E0433.
For more information about an error, try `rustc --explain E0425`.
error: Could not compile `alacritty_terminal`.

To learn more, run the command again with --verbose.
*** Error code 101

Stop.
make[1]: stopped in /usr/pkgsrc/wip/alacritty
*** Error code 1

Stop.
make: stopped in /usr/pkgsrc/wip/alacritty
teknokatze picture teknokatze on 13 Jul 2019

Yes, we can be sure. Please make sure you're on the latest version of this patch and it correctly includes the change of the Cargo.toml file.

If you are on the latest version and that does not fix it, please try removing the annotation above x11-dl = "2" completely and moving it below the [depedencies] header.

chrisduerr picture chrisduerr on 13 Jul 2019

I'm on the latest patch, including the Cargo.lock and toml.

So what is confusing right now is

+#[cfg(not(any(target_os = "macos", windows)))]

when I read page 176 in "Programming Rust", the example lists "macos" and "windows", but here we have windows, without the quotes.

teknokatze picture teknokatze on 13 Jul 2019

Windows is both a platform (like unix) and an operating system. macOS is part of unix, so we can't use just macos, but since there's no difference like that for Windows, we can just use it like that.

Anyways, that shouldn't matter if you remove it and move x11-dl section up to [dependencies]. Then it should be included regardless of the correctness of that annotation.

chrisduerr picture chrisduerr on 13 Jul 2019

Okay, thanks for the explanation.

I've got a bit of feedback in the pkgsrc irc channel, and I'm waiting on more, but I will try out your suggestion as soon as I can.

teknokatze picture teknokatze on 13 Jul 2019
👍1

So the main problem seems to be the target_os line in other files inside alacritty (not only the ones already patched). So either it's all changed like before or "netbsd" is added, which then is in-scope for the this ticket but as soon as someone will try this out for say illumos with pkgsrc, they will make me get back to you. Right now I have no idea what the better solution is.
I will get to the feedback of your suggested change later.

teknokatze picture teknokatze on 14 Jul 2019

@ng-0 All targets should be changed to not macos/windows if x11 is supported, that's the goal of this PR. I think I should have caught everything but I can't guarantee that of course.

Your current issue seems to be about the inclusion of x11-dl in the Cargo.toml (where depedencies are specified). If Alacritty complains about not finding something in use XXX, then the problem usually lies outside of the actual source code.

This is why my patch changed the section above x11-dl = "2" in the dependencies to something that I think should work (it worked for the source code too, as you've tested previously), so I'm a bit surprised it doesn't work now.

This is why I've suggested to just move x11-dl = "2" to the [depdencies] section for testing. That should circumvent any potential problems with the dependency not getting loaded and once we've figured that out we can try to find a more restrictive way to specify the dependency only for x11 systems.

chrisduerr picture chrisduerr on 14 Jul 2019

@ng-0 Someone pointed out that my PR currently still had a typo in it. With that resolved, I think it should "just work" now.

chrisduerr picture chrisduerr on 16 Jul 2019

Since there has been no more feedback, I've just gone ahead and merged the PR, since it should definitely improve the situation a bit. Please let me know if there are more problems you're running into and we can try to figure something out.

chrisduerr picture chrisduerr on 22 Jul 2019

I'm stuck between too much and 14 days delay is now normal for me. Anyway, thanks for pushing this! I did proceed a bit further with this, however ran into a wall of this:

          /usr/bin/ld: DWARF error: mangled line number section (bad file number)
          /usr/bin/ld: DWARF error: mangled line number section (bad file number)
          /usr/bin/ld: DWARF error: mangled line number section (bad file number)
          /usr/bin/ld: DWARF error: mangled line number section (bad file number)
          /usr/bin/ld: DWARF error: mangled line number section (bad file number)
          /usr/bin/ld: DWARF error: mangled line number section (bad file number)
          /usr/bin/ld: DWARF error: mangled line number section (bad file number)
          /usr/bin/ld: DWARF error: mangled line number section (bad file number)
          /usr/bin/ld: DWARF error: mangled line number section (bad file number)
          /usr/bin/ld: DWARF error: mangled line number section (bad file number)
          /usr/bin/ld: DWARF error: mangled line number section (bad file number)
          /usr/bin/ld: DWARF error: mangled line number section (bad file number)
          /usr/bin/ld: DWARF error: mangled line number section (bad file number)
          /usr/bin/ld: DWARF error: mangled line number section (bad file number)
          /usr/bin/ld: DWARF error: mangled line number section (bad file number)
          /usr/bin/ld: DWARF error: mangled line number section (bad file number)
          /usr/bin/ld: DWARF error: mangled line number section (bad file number)
          /usr/work/wip/alacritty/work/vendor/errno-0.2.4/src/unix.rs:42: undefined reference to `errno_location'
          /usr/bin/ld: /usr/work/wip/alacritty/work/vendor/errno-0.2.4/src/unix.rs:42: undefined reference to `errno_location'
          clang: 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.
*** Error code 101

Stop.
make[1]: stopped in /usr/pkgsrc/wip/alacritty
*** Error code 1

Stop.
make: stopped in /usr/pkgsrc/wip/alacritty
teknokatze picture teknokatze on 29 Jul 2019

Which, on close inspection appears as if it could be due to the errno crate and not alacritty, but I'd like to hear your opinion first.

teknokatze picture teknokatze on 29 Jul 2019

I've fixed the error in https://github.com/lfairy/rust-errno/pull/23. (new version seems not released yet)

iquiw picture iquiw on 29 Jul 2019
👍1

Thanks! I'll look into cherry-picking the patches if I can get to it, but I have to get to work soon. In the interest of portability and packaging, having alacrity handle this as a dependency bump seems to be in the best interest of pkgsrc.

teknokatze picture teknokatze on 29 Jul 2019
👍1

I've created https://github.com/jwilm/alacritty/pull/2698 to hopefully fix the remaining problems with NetBSD. Let me know if that doesn't work and there's more that needs to be done.

Otherwise I'll close this issue once the PR is merged.

chrisduerr picture chrisduerr on 4 Aug 2019

Many thanks, this works as intended - build passes beyond the previous failure.

Now:

error: linking with `cc` failed: exit code: 1
  |
  = note: "cc" "-Wl,--as-needed" "-Wl,-z,noexecstack" "-m64" "-L" "/usr/pkg/lib/rustlib/x86_64-unknown-netbsd/lib" "/usr/work/wip/alacritty/work/alacritty-e1892ee92ab6c826787e19c7d55de3f4b40e16a8/target/release/deps/alacritty-49d07d06d6256051.alacritty.3f2f60qr-cgu.4.rcgu.o" "-o" "/usr/work/wip/alacritty/work/alacritty-e1892ee92ab6c826787e19c7d55de3f4b40e16a8/target/release/deps/alacritty-49d07d06d6256051" "-Wl,--gc-sections" "-pie" "-Wl,-zrelro" "-Wl,-znow" "-Wl,-O1" "-L" "/usr/work/wip/alacritty/work/alacritty-e1892ee92ab6c826787e19c7d55de3f4b40e16a8/target/release/deps" "-L" "/usr/work/wip/alacritty/work/alacritty-e1892ee92ab6c826787e19c7d55de3f4b40e16a8/target/release/build/libloading-54962eafc1c61f54/out" "-L" "/usr/X11R7/lib" "-L" "/usr/lib" "-L" "/usr/X11R7/lib" "-L" "/usr/work/wip/alacritty/work/alacritty-e1892ee92ab6c826787e19c7d55de3f4b40e16a8/target/release/build/expat-sys-d401cd4d35d3c431/out/lib" "-L" "/usr/pkg/lib/rustlib/x86_64-unknown-netbsd/lib" "-Wl,-Bstatic" "/tmp/rustcQkyIx8/libexpat_sys-4641b350526c7246.rlib" "/tmp/rustcQkyIx8/liblibloading-35e9b4f709ae7d9d.rlib" "-Wl,--start-group" "/tmp/rustcQkyIx8/libbacktrace_sys-749b73eab3753a16.rlib" "-Wl,--end-group" "/usr/pkg/lib/rustlib/x86_64-unknown-netbsd/lib/libcompiler_builtins-e8f096599fb6ec9d.rlib" "-Wl,-Bdynamic" "-lfontconfig" "-lfreetype" "-lz" "-lbz2" "-lxcb" "-lxcb" "-lxcb" "-lxcb" "-lxcb-render" "-lxcb-shape" "-lxcb-xfixes" "-ldl" "-lutil" "-lrt" "-lutil" "-lexecinfo" "-lpthread" "-lrt" "-lgcc_s" "-lc" "-lm" "-lrt" "-lpthread" "-lutil" "-lrt" "-lutil"
  = note: /usr/bin/ld: cannot find -ldl
          clang: 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.
*** Error code 101

Will look into this as soon as I can, which is anywhere between tomorrow morning and on some weekend.

Thanks for your patience and support, chrisduerr!

teknokatze picture teknokatze on 4 Aug 2019

@ng-0 Ah, whats the output of cc -### on your system and rustc --version? As far as I've understood libdl doesn't exist on NetBSD at all, so this might be bug in rustc or some crate, which is forcing this.

kchibisov picture kchibisov on 4 Aug 2019
👍1

I got this part solved with help from the other NetBSD developers. There's an open question resulting from this which I might come back to but it's more meta about Cargo.
I got stuck at 3 linker problems in the end, but I'll get back to this if I can not make it build correctly.
So long story short it builds but it doesn't link correctly (3 libraries "missing"), which might be able to fix in pkgsrc.

teknokatze picture teknokatze on 4 Aug 2019
👍2

Thanks for looking into this so much. Please let us know how it turns out, so we can update the installation instructions for NetBSD appropriately.

chrisduerr picture chrisduerr on 4 Aug 2019

I've changed the tooling a bit, so now builds involve these invocations / make fragments:

do-build: do-build-cargo-binary
.PHONY: do-build-cargo-binary

do-build-cargo-binary:
        cd ${WRKSRC} && ${SETENV} ${MAKE_ENV} ${PREFIX}/bin/cargo build --locked --frozen --release --jobs ${MAKE_JOBS:U1}

do-install: install-cargo-binary
.PHONY: install-cargo-binary

install-cargo-binary:
        cd ${WRKSRC} && ${SETENV} ${MAKE_ENV} ${PREFIX}/bin/cargo install --jobs ${MAKE_JOBS:U1} --path . --root ${DESTDIR}${LOCALBASE}
        cd ${WRKSRC} && ${SETENV} ${MAKE_ENV} ${RM} ${DESTDIR}${LOCALBASE}/.crates.toml

.include "../../lang/rust/cargo.mk"
.include "../../lang/rust/buildlink3.mk"

this results in a problem in the build of alacritty:

    Finished release [optimized + debuginfo] target(s) in 27m 24s
*** Please use pkgtools/verifypc to sanity check dependencies.
===> Installing for alacritty-e1892ee92ab6c826787e19c7d55de3f4b40e16a8
=> Generating pre-install file lists
=> Creating installation directories
cd /usr/work/wip/alacritty/work/alacritty-e1892ee92ab6c826787e19c7d55de3f4b40e16a8 && /usr/bin/env OPENSSL_DIR=/usr USETOOLS=no PTHREAD_CFLAGS=\ -pthread\  PTHREAD_LDFLAGS=\ -pthread PTHREAD_LIBS= PTHREADBASE=/usr DL_CFLAGS=\ -pthread\  DL_LDFLAGS=\ -pthread DL_LIBS= PYTHON=/usr/pkg/bin/python3.7 CC=clang CFLAGS=-O2\ -I/usr/pkg/include\ -I/usr/include\ -I/usr/pkg/include/python3.7\ -I/usr/X11R7/include\ -I/usr/X11R7/include/freetype2 CPPFLAGS=-I/usr/pkg/include\ -I/usr/include\ -I/usr/pkg/include/python3.7\ -I/usr/X11R7/include\ -I/usr/X11R7/include/freetype2 CXX=clang++ CXXFLAGS=-O2\ -I/usr/pkg/include\ -I/usr/include\ -I/usr/pkg/include/python3.7\ -I/usr/X11R7/include\ -I/usr/X11R7/include/freetype2 COMPILER_RPATH_FLAG=-Wl,-R F77=false FC=false FFLAGS=-O LANG=C LC_ALL=C LC_COLLATE=C LC_CTYPE=C LC_MESSAGES=C LC_MONETARY=C LC_NUMERIC=C LC_TIME=C LDFLAGS=-L/usr/pkg/lib\ -L/usr/lib\ -Wl,-R/usr/lib\ -L/usr/X11R7/lib\ -Wl,-R/usr/X11R7/lib\ -Wl,-R/usr/pkg/lib LINKER_RPATH_FLAG=-R PATH=/usr/work/wip/alacritty/work/.cwrapper/bin:/usr/work/wip/alacritty/work/.buildlink/bin:/usr/work/wip/alacritty/work/.tools/bin:/usr/pkg/bin:/home/ng0/bin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/X11R7/bin:/usr/pkg/bin:/usr/pkg/sbin:/usr/games:/usr/local/bin:/usr/local/sbin:/home/ng0/code/dev/prefix/bin:/home/ng0/code/dev/prefix/bin:/usr/pkg/bin:/usr/X11R7/bin PREFIX=/usr/pkg MAKELEVEL=0 CONFIG_SITE= PKG_SYSCONFDIR=/usr/pkg/etc HOME=/usr/work/wip/alacritty/work/.home CWRAPPERS_CONFIG_DIR=/usr/work/wip/alacritty/work/.cwrapper/config CPP=clang-cpp LOCALBASE=/usr/pkg X11BASE=/usr/X11R7 PKGMANDIR=man PKGINFODIR=info PKGGNUDIR=gnu/ MAKECONF=/dev/null OBJECT_FMT=ELF USETOOLS=no BSD_INSTALL_PROGRAM=/usr/bin/install\ -c\ -s\ -o\ ng0\ -g\ users\ -m\ 755 BSD_INSTALL_SCRIPT=/usr/bin/install\ -c\ -o\ ng0\ -g\ users\ -m\ 755 BSD_INSTALL_LIB=/usr/bin/install\ -c\ -o\ ng0\ -g\ users\ -m\ 755 BSD_INSTALL_DATA=/usr/bin/install\ -c\ -o\ ng0\ -g\ users\ -m\ 644 BSD_INSTALL_MAN=/usr/bin/install\ -c\ -o\ ng0\ -g\ users\ -m\ 644 BSD_INSTALL=/usr/bin/install BSD_INSTALL_PROGRAM_DIR=/usr/bin/install\ -d\ -o\ ng0\ -g\ users\ -m\ 755 BSD_INSTALL_SCRIPT_DIR=/usr/bin/install\ -d\ -o\ ng0\ -g\ users\ -m\ 755 BSD_INSTALL_LIB_DIR=/usr/bin/install\ -d\ -o\ ng0\ -g\ users\ -m\ 755 BSD_INSTALL_DATA_DIR=/usr/bin/install\ -d\ -o\ ng0\ -g\ users\ -m\ 755 BSD_INSTALL_MAN_DIR=/usr/bin/install\ -d\ -o\ ng0\ -g\ users\ -m\ 755 BSD_INSTALL_GAME=/usr/bin/install\ -c\ -s\ -o\ ng0\ -g\ users\ -m\ 2555 BSD_INSTALL_GAME_DATA=/usr/bin/install\ -c\ -o\ ng0\ -g\ users\ -m\ 664 BSD_INSTALL_GAME_DIR=/usr/bin/install\ -d\ -o\ ng0\ -g\ users\ -m\ 775 INSTALL_INFO= MAKEINFO=/usr/work/wip/alacritty/work/.tools/bin/makeinfo FLEX= BISON= PKG_CONFIG=/usr/work/wip/alacritty/work/.tools/bin/pkg-config PKG_CONFIG_LIBDIR=/usr/work/wip/alacritty/work/.buildlink/lib/pkgconfig:/usr/work/wip/alacritty/work/.buildlink/share/pkgconfig PKG_CONFIG_LOG=/usr/work/wip/alacritty/work/.pkg-config.log PKG_CONFIG_PATH= CWRAPPERS_CONFIG_DIR=/usr/work/wip/alacritty/work/.cwrapper/config /usr/pkg/bin/cargo install --jobs 1 --path . --root /usr/work/wip/alacritty/work/.destdir/usr/pkg
error: found a virtual manifest at `/usr/work/wip/alacritty/work/alacritty-e1892ee92ab6c826787e19c7d55de3f4b40e16a8/Cargo.toml` instead of a package manifest
*** Error code 101

Stop.
make[1]: stopped in /usr/pkgsrc/wip/alacritty
*** Error code 1

Stop.
make: stopped in /usr/pkgsrc/wip/alacritty

this is not a general problem, some binary crates build, yours is the 3rd I'm testing and the first where I experience this. I tried to work around it by adding --package, --all, or --all-features to the cargo invocations but it doesn't help. Do you have any idea what could be wrong?

teknokatze picture teknokatze on 24 Aug 2019

Yeah, the Cargo.toml in the root of the Alacritty project is not actually the Alacritty binary. Alacritty is using Rust workspaces. Instead, the realy Cargo.toml you want to use is in alacritty/Cargo.toml.

You might be able to run it with cargo build --bin alacritty. Though with a custom build like that there's so many problems you could be introducing, it'll likely involve a bunch of trial and error. That's usually why I try to stay away from third party build tools.

chrisduerr picture chrisduerr on 24 Aug 2019

Thanks.

This is not about building but installing though, target/release/alacritty gets build even with the lines given. I guess for now I'll just revert to overwriting this in the instruction for alacritty.

teknokatze picture teknokatze on 24 Aug 2019

error: found a virtual manifest at /usr/work/wip/alacritty/work/alacritty-e1892ee92ab6c826787e19c7d55de3f4b40e16a8/Cargo.toml instead of a package manifest

This is a cargo build failure. It should completely prevent cargo from building the binary. Are you sure the binary in target/release/alacritty is not just left over from a previous attempt? The error usually occurs in extremely early stages of the build process, before anything else is done (or the output directory is cleared).

chrisduerr picture chrisduerr on 24 Aug 2019

yes, make clean of pkgsrc completely cleans the work directory -> basically rm -rf.

What we do is less magic. if you consider the 2 relevant mk files, we fetch the crates in advances, vendor them and tell the source to build that the dependencies are vendored in a specific directory. This is like any package manager not allowing any network connection during build, standard procedure with rust.

Before asking I've read into this error and I'm really confused why this manages to build, like you are.

teknokatze picture teknokatze on 24 Aug 2019

What we do is less magic. if you consider the 2 relevant mk files, we fetch the crates in advances, vendor them and tell the source to build that the dependencies are vendored in a specific directory.

You might be doing less things in general, however you're doing much more things yourself outside of the expected cargo workflow. So things are much more likely to go wrong and resources for fixing them are much more scarce.

If you get an error building Alacritty following the official documentation, I'm always happy to help. But like this you're mostly on your own (ofc I'm down to help when I can, chances are just lower that I can).

Have you actually managed to build and run Alacritty properly using remote sources? That should always be the first step before trying out some custom build tools.

chrisduerr picture chrisduerr on 25 Aug 2019

If you get an error building Alacritty following the official documentation, I'm always happy to help. But like this you're mostly on your own (ofc I'm down to help when I can, chances are just lower that I can).

I know, and I appreciate that. For this, I just asked for advice, not for help.

Have you actually managed to build and run Alacritty properly using remote sources? That should always be the first step before trying out some custom build tools.

Why I use pkgsrc directly is that pkgsrc helps building non-trivial pieces of software on NetBSD more easily. I have to apply a patch for the xcb crate first, mainly to change the wrong hardcoded python name. Without this the build fails here. Moving on I need to pass on a bunch of environment variables down to cargo. I might succeed, but I crash at many steps possibly including the last one.

To answer your question, yes initially I've tried that.

teknokatze picture teknokatze on 25 Aug 2019

I have to apply a patch for the xcb crate first, mainly to change the wrong hardcoded python name. Without this the build fails here.

Rather than trying to work around this, I'm sure upstream would really appreciate a patch if it is simple and improves cross-platform support.

Moving on I need to pass on a bunch of environment variables down to cargo.

It should be possible just to specify these while running cargo, right?

Don't get me wrong, I am completely fine with you using pkgsrc. I'm just trying to figure out a way to approach this problem in more simple and straight forward steps rather than trying to climb a massive wall by running at it repeatedly.

chrisduerr picture chrisduerr on 25 Aug 2019

I have to apply a patch for the xcb crate first, mainly to change the wrong hardcoded python name. Without this the build fails here.

Rather than trying to work around this, I'm sure upstream would really appreciate a patch if it is simple and improves cross-platform support.

Yes, pkgsrc policy is not to keep patches, and everything but this https://github.com/rtbo/rust-xcb/issues/62 is upstream, so it's just a matter of waiting.

Moving on I need to pass on a bunch of environment variables down to cargo.

It should be possible just to specify these while running cargo, right?

Don't get me wrong, I am completely fine with you using pkgsrc. I'm just trying to figure out a way to approach this problem in more simple and straight forward steps rather than trying to climb a massive wall by running at it repeatedly.

It's not that easy. I can see how far I get, but for me this approach is the one which is the massive wall given how much I learned about what still needs to be done in cargo itself to be properly integrated with systems (passing variables through was just the beginning of a really interesting learning experience of what's not possible today or really hard). In any case, I will get back to you as soon as I have results.

teknokatze picture teknokatze on 25 Aug 2019
👍2

small update: with 0.5.0 I'm now down to linking:

=> Checking for missing run-time search paths in alacritty-v0.5.0
ERROR: bin/alacritty: missing library: libfreetype.so.19
ERROR: bin/alacritty: missing library: libfontconfig.so.2
ERROR: bin/alacritty: missing library: libxcb.so.2

This however might or might not be a problem we had before, but alacritty is low priority for me right now because of more important things in life right now.

Edit: I have been there before. Aha.

teknokatze picture teknokatze on 6 Aug 2020

On AMD64 NetBSD-current, at the moment on 9.99.71, I get, besides the above, also as follows:

RUST_BACKTRACE=full WINIT_UNIX_BACKEND=x11 LD_LIBRARY_PATH=/usr/X11R7/lib:/usr/pkg/lib  alacritty
thread 'main' panicked at 'Initializing the event loop outside of the main thread is a significant cross-platform compatibility hazard. If you really, absolutely need to create an EventLoop on a different thread, please use the `EventLoopExtUnix::new_any_thread` function.', /usr/pkgsrc/wip/alacritty/work/vendor/winit-0.22.2/src/platform_impl/linux/mod.rs:703:9
stack backtrace:
   0:         0xbab84809 - <unknown>
   1:         0xbaa776ec - <unknown>
   2:         0xbab7eda6 - <unknown>
   3:         0xbab78715 - <unknown>
   4:         0xbab7829d - <unknown>
   5:         0xbab77f38 - <unknown>
   6:         0xbab77ee0 - <unknown>
   7:         0xba8d8d7c - <unknown>
   8:         0xbab844b3 - <unknown>
   9:         0xba8cfd5e - <unknown>
  10:         0xba863d3b - <unknown>

Otherwise it builds with only two deprecation warnings. Rust is on 1.44.1. The above trace is from a build from almost two weeks ago, but with the today's build it remained exactly the same.

ci4ic4 picture ci4ic4 on 19 Aug 2020

@ci4ic4 Would be useful to get the full backtrace for that. This error should not happen on the latest master.

chrisduerr picture chrisduerr on 19 Aug 2020

@ci4ic4 Would be useful to get the full backtrace for that. This error should not happen on the latest master.

AFAIU this is the full backtrace - the command starts with RUST_BACKTRACE=full.

ci4ic4 picture ci4ic4 on 19 Aug 2020

Yeah but all symbols are stripped, making it rather useless.

chrisduerr picture chrisduerr on 19 Aug 2020

Well, the only way it could crash like that is due to creation of event loop in winit, since it checks for main thread, maybe it's not considered as such on netbsd, but anyway, it could be helpful to get backtrace with debug symbols.

kchibisov picture kchibisov on 19 Aug 2020

I just built it from pkgsrc/wip, if you suggest to me how to repeat the build with debug symbols I would do it, of course.

ci4ic4 picture ci4ic4 on 19 Aug 2020

I just built it from pkgsrc/wip, if you suggest to me how to repeat the build with debug symbols I would do it, of course.

From source. Testing some random repository would make it rather difficult to reproduce any problems you run into.

chrisduerr picture chrisduerr on 19 Aug 2020

You probably are not aware how pkgsrc works. It fetches and builds everything from source, from the release tarballs if the upstream package is on GitHub. The distinfo file in use contains 

SHA1 (alacritty-v0.5.0.tar.gz) = 24f9ff3fac849f06416d1f5b5b4749bba85465f4
RMD160 (alacritty-v0.5.0.tar.gz) = e3fa9fb2fe9efe2999f6e0f16a5c9aec9f53ef59
SHA512 (alacritty-v0.5.0.tar.gz) = 53ecda7996473890eea90b01b3f71c32d07abc38072dbc40ef3ccbc500a747af866e5b5aeea0ae0b85dc17e0b3c16fc9c5e3bae1a0d0f9a88c5ac264f51af62e

plus another 256 crate definitions. The release tarball of alacritty itself is from the 6th of August.

I was looking for a suitable rustc switch to build and link it with debug symbols.

ci4ic4 picture ci4ic4 on 19 Aug 2020

The default build is with debug symbols, don't strip the binary. I'm sure your package manager should be capable of not doing so.

kchibisov picture kchibisov on 19 Aug 2020
👍1

You are right. The image is stripped by default at the moment of installation. There was still an unstripped version in the build tree, the out put is as follows:

RUST_BACKTRACE=full WINIT_UNIX_BACKEND=x11 LD_LIBRARY_PATH=/usr/X11R7/lib:/usr/pkg/lib  ./alacritty
thread 'main' panicked at 'Initializing the event loop outside of the main thread is a significant cross-platform compatibility hazard. If you really, absolutely need to create an EventLoop on a different thread, please use the `EventLoopExtUnix::new_any_thread` function.', /usr/pkgsrc/wip/alacritty/work/vendor/winit-0.22.2/src/platform_impl/linux/mod.rs:703:9
stack backtrace:
   0:         0x1cf84809 - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::h696b0c7164c42b89
   1:         0x1ce776ec - core::fmt::write::h3e4f7bb56331df60
   2:         0x1cf7eda6 - std::io::Write::write_fmt::hd6b629b0842160ba
   3:         0x1cf78715 - std::panicking::default_hook::{{closure}}::h8b30e814058b19b5
   4:         0x1cf7829d - std::panicking::rust_panic_with_hook::h3062351663ff3949
   5:         0x1cf77f38 - rust_begin_unwind
   6:         0x1cf77ee0 - std::panicking::begin_panic_fmt::h8b1f010f0b35211e
   7:         0x1ccd8d7c - winit::platform_impl::platform::assert_is_main_thread::h3105b1f3a5f2dee9
                               at /usr/pkgsrc/wip/alacritty/work/vendor/winit-0.22.2/src/platform_impl/linux/mod.rs:703
   8:         0x1ccd8d7c - winit::platform_impl::platform::EventLoop<T>::new::h1238e8f8d9d65e9a
                               at /usr/pkgsrc/wip/alacritty/work/vendor/winit-0.22.2/src/platform_impl/linux/mod.rs:531
   9:         0x1ccd8d7c - winit::event_loop::EventLoop<T>::with_user_event::h2a9c013754dd7b1e
                               at /usr/pkgsrc/wip/alacritty/work/vendor/winit-0.22.2/src/event_loop.rs:129
  10:         0x1ccd8d7c - alacritty::main::hde70bbc298dd3f59
                               at alacritty/src/main.rs:81
  11:         0x1cf844b3 - std::sys_common::backtrace::__rust_begin_short_backtrace::hc4d5a95302ccc82d
  12:         0x1cccfd5e - main
  13:         0x1cc63d3b - ___start
ci4ic4 picture ci4ic4 on 19 Aug 2020

So, somehow it thinks that we're not on a main thread even though we don't change threads, maybe the checking of the main thread is borken in winit for netbsd.

kchibisov picture kchibisov on 19 Aug 2020

I've appraised the current-users NetBSD list, hope somewone would help.

ci4ic4 picture ci4ic4 on 19 Aug 2020

The code is super simple: https://github.com/rust-windowing/winit/blob/3d5d05eac7d23c78e4e66789563b3d4285e3a4eb/src/platform_impl/linux/mod.rs#L717-L736

Would you mind checking what that syscall returns for you? The simplest example would probably to just make a small Rust executable yourself and see what it usually returns.

Just the following should work:

use libc::_lwp_self;
fn main() {
    println!("{:?}", unsafe { _lwp_self() });
}

Then you just need to add libc = * in the Cargo.toml after creating the project with cargo new testing.

If it does indeed return 1 consistently, then the next best test would probably be to just see what it logs in winit by cloning and patching the repo.

chrisduerr picture chrisduerr on 19 Aug 2020 
➜  testing (master) ✗ cat src/main.rs
use libc::_lwp_self;
fn main() {
    println!("{:?}", unsafe { _lwp_self() });
}
➜  testing (master) ✗ ./target/debug/testing
23026

Seems to work.

ci4ic4 picture ci4ic4 on 19 Aug 2020

Seems to work.

It doesn't. If you check the code, it makes sure that the return code of _lwp_self() is equal to 1 to check if it is the main thread. Last time I checked 23026 is not 1! So that cannot be used to check for the main thread on NetBSD.

Could you try the following?

fn main() {
    println!("{:?}", std::thread::current().id());
    println!("{:?}", std::thread::current().name());
}
chrisduerr picture chrisduerr on 19 Aug 2020 
➜  testing2 (master) ✗ cat src/main.rs
fn main() {
    println!("{:?}", std::thread::current().id());
    println!("{:?}", std::thread::current().name());
}
➜  testing2 (master) ✗ ./target/debug/testing2
ThreadId(1)
Some("main")
ci4ic4 picture ci4ic4 on 20 Aug 2020

Seems like one could use TID == 1 as an identification for NetBSD then, thanks. I'll send a patch.

chrisduerr picture chrisduerr on 20 Aug 2020

Good. My Rust knowledge is not even. well, rusty. At least I can type 'cargo build'...

ci4ic4 picture ci4ic4 on 20 Aug 2020
😄1

I've fixed it upstream in https://github.com/rust-windowing/winit/pull/1664. Running this patch should allow you to make things work.

chrisduerr picture chrisduerr on 20 Aug 2020

Also, could you try checking the following C code? I'm not sure how rust returns 1 there, but anyway, it'll be nice to ensure that C code doesn't return 1.

#include <lwp.h>
#include <stdio.h>

int main(void) {
    lwpid_t tid = _lwp_self();
    printf("%d\n", tid); 
    return 0;
}
kchibisov picture kchibisov on 20 Aug 2020

@kchibisov I feel like it might actually be that _lwp_self() returns PID. But that's just a guess basically.

chrisduerr picture chrisduerr on 20 Aug 2020 
➜  xcc cat t.c
#include <lwp.h>
#include <stdio.h>

int main(void) {
    lwpid_t tid = _lwp_self();
    printf("%d\n", tid);
    return 0;
}

➜  xcc ./t
22205
➜  xcc ./t
20130
➜  xcc ./t
22420

So it's the pid.

ci4ic4 picture ci4ic4 on 20 Aug 2020

alacritty-netbsd-02.log

With the patch it goes further, but still no go...

ci4ic4 picture ci4ic4 on 20 Aug 2020

So it's the pid.

Is it? It seems to be jumping around a lot for a PID. Those usually don't just drop by 2000. You'd also have to print the PID to check.

chrisduerr picture chrisduerr on 20 Aug 2020

@ci4ic4 are you aware of a C way to get TID on netbsd? It's a bit hard to search for netbsd stuff on the web tbqh, so if there's a known interface for that it could be really helpful.

kchibisov picture kchibisov on 20 Aug 2020

@kchibisov You mean to use libc to get TID to use that instead of the name?

chrisduerr picture chrisduerr on 20 Aug 2020

With the patch it goes further, but still no go...

Does netbsd has a concept of locale? I'd assume that that's why it's failing here? If it does could you share what your locale is(things like LC_CTYPE, etc).

kchibisov picture kchibisov on 20 Aug 2020 
➜  ~ locale
LANG="en_GB.UTF-8"
LC_CTYPE="en_GB.UTF-8"
LC_COLLATE="C"
LC_TIME="en_GB.UTF-8"
LC_NUMERIC="en_GB.UTF-8"
LC_MONETARY="en_GB.UTF-8"
LC_MESSAGES="en_GB.UTF-8"
LC_ALL=""
ci4ic4 picture ci4ic4 on 20 Aug 2020

@kchibisov You mean to use libc to get TID to use that instead of the name?

Yeah, but such things are very different and there's no common interface to do so, even in libc. On linux + glibc there's a gettid, but it's only since glibc 2.30, otherwise you're stuck with syscall, on macOS/freebsd/openbsd there's a pthread_main_np.

kchibisov picture kchibisov on 20 Aug 2020
👍1

@ci4ic4 could you try running it with LC_ALL=en_GB.UTF-8

kchibisov picture kchibisov on 20 Aug 2020

Ï get the same with LC_ALL set to en_GB.UTF-8.

As far as pthreads on NetBSD, the man page says

The pthread library conforms to IEEE Std 1003.1-2001 (“POSIX.1”).

There are NetBSD-specific extensions - pthread_attr_get_np and pthread_attr_getname_np, which may be of use.

ci4ic4 picture ci4ic4 on 20 Aug 2020

The semantics of _lwp_self() has been refactored and PID and LWP share now the same namespace, so 1 is no longer true for the first thread.

krytarowski picture krytarowski on 22 Aug 2020

I think you can close this issue. I have been using alacritty on NetBSD for a couple of weeks now and found no more problems.

tnn2 picture tnn2 on 22 Oct 2020

Thanks for letting us know!

chrisduerr picture chrisduerr on 22 Oct 2020
Was this page helpful?
0 / 5 - 0 ratings

Related issues

spamwax picture spamwax  ·  50Comments
VickyJin picture VickyJin  ·  46Comments
pikajude picture pikajude  ·  62Comments
i336 picture i336  ·  99Comments
net picture net  ·  112Comments