GToolkit crash on startup - glutin loads an unrelated libGLE.dll from PATH

[NightRa]

Scenario: Downloaded release, GToolkit.exe crashes on startup.
While debugging it, I noticed that there were unrelated library loads:
C:\Program Files\SciTools\bin\pc-win64\libEGL.dll
C:\Program Files\SciTools\bin\pc-win64\libGLESv2.dll

The flow which causes this load is:
glutin_create_headless_context (libGlutin) -> build_headless (glutin_sys) -> new_headless -> EGL lazy static -> LoadLibrary

In new_headless, if no windowed sharing was specified, it tries to load libEGL.dll from the load path, which in my case was in PATH from another program (SciTools Understand for reading code), so it used it instead of the windows-based solution which is typically used in Pharo - and it led to a crash later on.
From new_headless:

match (gl_attr.sharing, &*EGL) {
  (None, Some(_)) => // Use EGL
  ...
}

The fallback flow of new_headless is the following:

let wb = WindowBuilder::new()
    .with_visible(false)
    .with_inner_size(size);
Self::new_windowed(wb, &el, pf_reqs, gl_attr).map(|(win, context)| {
    match context {
        Context::Egl(context) => Context::HiddenWindowEgl(win, context),
        Context::Wgl(context) => Context::HiddenWindowWgl(win, context),
        _ => unreachable!(),
    }
})

So a solution to avoid the use of EGL is to use build_windowed -> new_windowed instead of build_headless in libGlutin with with_visible(false) - and this would avoid the usage of libEGL.

In the meantime, removing SciTools Understand from PATH is a workaround for the issue.

[NightRa]

Note this is the implementation of new_headless on windows - which has the fallback.
Unix seems to have a more native impl for headless windows - so depends how much of a difference it makes, one could either always use an invisible window in libGlutin or just do it for Windows.

Another option would be to change glutin-sys to avoid optimistically loading libEGL (and only do it if asked to)

[NightRa]

This issue has been moved to feenkcom/libglutin#2

[girba]

No. Please keep it here.

[syrel]

I opened an issue in glutin itself rust-windowing/glutin#1292
thank you for debugging this! it is very helpful 👍

[NightRa]

Verified that using the fixed glutin version (syrel/glutin#1) in libGlutin indeed solves the startup issue.

[girba]

Great to hear!

[girba]

Would you be able to try again? We have changed quite a bit of things in the meantime.

[girba]

@NightRa: This issue is likely addressed now. Please let us know if you still encounter problems with starting GT.