Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Native builds with SDL and GLFW are incompatible, so should have different SONAMEs #3321

Closed
smcv opened this issue Mar 30, 2023 · 5 comments · Fixed by #3738 · May be fixed by #3324
Closed

Native builds with SDL and GLFW are incompatible, so should have different SONAMEs #3321

smcv opened this issue Mar 30, 2023 · 5 comments · Fixed by #3738 · May be fixed by #3324

Comments

@smcv
Copy link

smcv commented Mar 30, 2023

As far as I can tell, each of the available WSIs for DXVK Native has a different ABI: in the SDL2 WSI, whenever a function in the DirectX API returns or receives a HWND it's really a SDL_Window *, but in the GLFW WSI, whenever a function returns or receives a HWND it's really a GLFWwindow *.

When SDL 3 becomes stable, presumably there will be SDL3 games that want to use DXVK Native, at which point that would become a third incompatible WSI?

If that's the case, then they should have different SONAMEs. One option would be to append the WSI to the dxvk_name_prefix, making them libdxvk_sdl2_d3d9.so, libdxvk_glfw_d3d9.so and so on. libdxvk_d3d9.so could be a symlink to libdxvk_sdl2_d3d9.so, and so on, for backwards compatibility.

Or, the default sdl2 WSI could use an unadorned name because it got there first, and all other WSIs (including SDL3, GLFW, and any other WSIs that are invented in future) could append their name to the dxvk_name_prefix?
@smcv
Copy link
Author

smcv commented Mar 30, 2023

cc @Joshua-Ashton

@smcv smcv changed the title Builds with SDL and GLFW are incompatible, so should have different SONAMEs Native builds with SDL and GLFW are incompatible, so should have different SONAMEs Mar 30, 2023
@Joshua-Ashton
Copy link
Collaborator

I think the true game plan to solve this is simply to add an interface that lets the dev pick the WSI at runtime.

In the meantime though, I am happy to append the other WSI such as GLFW to the name prefix.
We don't provide builds with the glfw WSI in releases right now either fwiw.

@smcv
Copy link
Author

smcv commented Mar 30, 2023

In the meantime though, I am happy to append the other WSI such as GLFW to the name prefix

OK, I'll do a PR to make it libdxvk_d3d9.so (implicitly SDL2) and libdxvk_glfw_d3d9.so.

@doitsujin
Copy link
Owner

yeah i can live with that as a temporary solution, but as josh said, we should rework this at some point.

smcv added a commit to smcv/dxvk that referenced this issue Mar 31, 2023
@smcv
build: Use a different SONAME for the glfw WSI
04113bd 
Selecting the GLFW WSI gives DXVK an incompatible ABI: for example,
CreateDevice takes a `SDL_Window *` parameter in the default SDL WSI,
but takes a `GLFWwindow *` instead in the GLFW WSI. This means it
should get a different name, so that binaries expecting one WSI don't
unexpectedly load the other.

Resolves: doitsujin#3321
Signed-off-by: Simon McVittie <smcv@collabora.com>
@smcv smcv mentioned this issue Mar 31, 2023
Open
@Beyley
Copy link
Contributor

Beyley commented May 4, 2023

I think the true game plan to solve this is simply to add an interface that lets the dev pick the WSI at runtime.

In the meantime though, I am happy to append the other WSI such as GLFW to the name prefix. We don't provide builds with the glfw WSI in releases right now either fwiw.

Different so names is something we do downstream at Silk.NET to handle this problem and it works great, but when the runtime WSI selection does happen, could you drop me a ping if you remember so i can update our native lib handling?

@flibitijibibo flibitijibibo mentioned this issue May 25, 2023
Open
3 tasks
@flibitijibibo flibitijibibo mentioned this issue Dec 8, 2023
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
4 participants
@smcv @Joshua-Ashton @doitsujin @Beyley