glutin breaks after using azul

[CryZe]

Description

This is a very strange bug. But the scenario is that I open an azul window, close it and then use glutin to create another window. Even minimal usage of glutin (without even initializing gl) completely breaks.

Version / OS

• azul version: 8586f0f
• Operating system: Windows 10 (this likely is specific to Windows)

Steps to Reproduce

app.run(Window::new(window_options, css).unwrap()).unwrap();

let events_loop = glutin::EventsLoop::new();
let window = glutin::WindowBuilder::new().build(&events_loop).unwrap();

Expected Behavior

The second window shows up.

Actual Behavior

The code panics deep within winit.

Additional Information

If you replace glutin with winit it works. So this must be something that glutin does in addition to winit's logic.

[CryZe]

It seems to work if I use the same glutin version as azul (0.17.0). Both 0.18.0 and 0.19.0 cause this bug. So that's either because of the version mismatch or because they "broke" something in 0.18.0. Although shouldn't a version mismatch mean that they are fully distinct and thus no global variables or whatever could influence each other? The panic is a lazy_static that is a None when it shouldn't be. So I don't think a version mismatch could cause that.

[fschutt]

This is likely a bug with winit, because winit uses a static global cache for pushing messages around. This is likely not a bug in azul itself.

[fschutt]

@CryZe Rust recognizes two major crate versions as two different things. I have now updated glutin and winit (to 0.19 and 0.18 respectively), maybe try again.