How to handle distributing shared libraries with different compile flags?
I am building a shared library which uses compiler flags to load different window manager apis:
-DVK_USE_PLATFORM_WAYLAND_KHR
and
-DVK_USE_PLATFORM_XCB_KHR
An application is then compiled against the compiled shared library with its on wayland or xcb flag.
What is the standard practice for distributing and loading the compiled library on runtime? Should I produce separate binaries (i.e. sharedlib.wayland.so and sharedlib.xcb.so), as well as separate executables (i.e. app.wayland and app.xcb) for each?
c++ vulkan
asked Nov 14 '18 at 2:20
coffeesagacoffeesaga
371315
add a comment |
I am building a shared library which uses compiler flags to load different window manager apis:
-DVK_USE_PLATFORM_WAYLAND_KHR
and
-DVK_USE_PLATFORM_XCB_KHR
An application is then compiled against the compiled shared library with its on wayland or xcb flag.
What is the standard practice for distributing and loading the compiled library on runtime? Should I produce separate binaries (i.e. sharedlib.wayland.so and sharedlib.xcb.so), as well as separate executables (i.e. app.wayland and app.xcb) for each?
c++ vulkan
asked Nov 14 '18 at 2:20
coffeesagacoffeesaga
371315
2
Is there some reason why you can't just have both, and decide which API to use based on what's available on the user's system or by user settings? I'm not a Linux user, so I don't know much about this.
– Nicol Bolas
Nov 14 '18 at 2:29
1
Yes, I was considering this! That would mean I'd add #include headers for both APIs for the Linux build, would that be okay?
– coffeesaga
Nov 14 '18 at 2:35
1
Yes, including headers for both and deciding which to use at runtime and deciding which to use at runtime is fine and probably best if you're distributing binaries.
– Jesse Hall
Nov 14 '18 at 3:53
add a comment |
I am building a shared library which uses compiler flags to load different window manager apis:
-DVK_USE_PLATFORM_WAYLAND_KHR
and
-DVK_USE_PLATFORM_XCB_KHR
An application is then compiled against the compiled shared library with its on wayland or xcb flag.
What is the standard practice for distributing and loading the compiled library on runtime? Should I produce separate binaries (i.e. sharedlib.wayland.so and sharedlib.xcb.so), as well as separate executables (i.e. app.wayland and app.xcb) for each?
c++ vulkan
asked Nov 14 '18 at 2:20
coffeesagacoffeesaga
371315
I am building a shared library which uses compiler flags to load different window manager apis:
-DVK_USE_PLATFORM_WAYLAND_KHR
and
-DVK_USE_PLATFORM_XCB_KHR
An application is then compiled against the compiled shared library with its on wayland or xcb flag.
What is the standard practice for distributing and loading the compiled library on runtime? Should I produce separate binaries (i.e. sharedlib.wayland.so and sharedlib.xcb.so), as well as separate executables (i.e. app.wayland and app.xcb) for each?
c++ vulkan
c++ vulkan
asked Nov 14 '18 at 2:20
coffeesagacoffeesaga
371315
asked Nov 14 '18 at 2:20
coffeesagacoffeesaga
371315
edited Nov 14 '18 at 2:26
coffeesaga
asked Nov 14 '18 at 2:20
coffeesagacoffeesaga
371315
asked Nov 14 '18 at 2:20
coffeesagacoffeesaga
371315
asked Nov 14 '18 at 2:20
coffeesagacoffeesaga
371315
371315
2
Is there some reason why you can't just have both, and decide which API to use based on what's available on the user's system or by user settings? I'm not a Linux user, so I don't know much about this.
– Nicol Bolas
Nov 14 '18 at 2:29
1
Yes, I was considering this! That would mean I'd add #include headers for both APIs for the Linux build, would that be okay?
– coffeesaga
Nov 14 '18 at 2:35
1
Yes, including headers for both and deciding which to use at runtime and deciding which to use at runtime is fine and probably best if you're distributing binaries.
– Jesse Hall
Nov 14 '18 at 3:53
add a comment |
2
Is there some reason why you can't just have both, and decide which API to use based on what's available on the user's system or by user settings? I'm not a Linux user, so I don't know much about this.
– Nicol Bolas
Nov 14 '18 at 2:29
1
Yes, I was considering this! That would mean I'd add #include headers for both APIs for the Linux build, would that be okay?
– coffeesaga
Nov 14 '18 at 2:35
1
Yes, including headers for both and deciding which to use at runtime and deciding which to use at runtime is fine and probably best if you're distributing binaries.
– Jesse Hall
Nov 14 '18 at 3:53
2
2
Is there some reason why you can't just have both, and decide which API to use based on what's available on the user's system or by user settings? I'm not a Linux user, so I don't know much about this.
– Nicol Bolas
Nov 14 '18 at 2:29
Is there some reason why you can't just have both, and decide which API to use based on what's available on the user's system or by user settings? I'm not a Linux user, so I don't know much about this.
– Nicol Bolas
Nov 14 '18 at 2:29
1
1
Yes, I was considering this! That would mean I'd add #include headers for both APIs for the Linux build, would that be okay?
– coffeesaga
Nov 14 '18 at 2:35
Yes, I was considering this! That would mean I'd add #include headers for both APIs for the Linux build, would that be okay?
– coffeesaga
Nov 14 '18 at 2:35
1
1
Yes, including headers for both and deciding which to use at runtime and deciding which to use at runtime is fine and probably best if you're distributing binaries.
– Jesse Hall
Nov 14 '18 at 3:53
Yes, including headers for both and deciding which to use at runtime and deciding which to use at runtime is fine and probably best if you're distributing binaries.
– Jesse Hall
Nov 14 '18 at 3:53
add a comment |
1 Answer
1
active
oldest
votes
As I said in the comment, I think you actually want to decide at runtime. But to answer the question you asked:
What it looks like you're doing is creating an abstract interface to any Vulkan window system, and putting different implementations of that interface into their own shared libraries. You have to name the libraries differently, e.g. libvkwsi-wayland.so, libvkwsi-xcb.so.
Usually, people will have a single executable that decides which implementation to use, and uses dlopen to load the corresponding shared library. You then need to use dlsym to get function pointers for functions in that library. If you're using C++ and the abstract interface is a literal abstract base class, then your shared libraries would have a single standalone function which creates and returns an instance of a class derived from that abstract class. The application would call that factory function, and from then on could just make virtual function calls into the object like normal.
If you want to directly link against the shared library ("-l" flag at executable link time), then you have to have a separate executable per window system (myapp-wayland, myapp-xcb, etc.). In that case, you'd probably also want to have a shell or python script that figures out which window system to use and then invokes the right executable -- that way your users don't need to know what window system they should use (fine for advanced users, not so much for most people).
Using separate executables means you're effectively distributing multiple copies of your entire application, even though nearly all of it is probably identical between window systems.
answered Nov 14 '18 at 4:02
Jesse HallJesse Hall
3,6821220
add a comment |
Your Answer
StackExchange.ifUsing("editor", function ()
StackExchange.using("externalEditor", function ()
StackExchange.using("snippets", function ()
StackExchange.snippets.init();
);
);
, "code-snippets");
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "1"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);
else
createEditor();
);
function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53292280%2fhow-to-handle-distributing-shared-libraries-with-different-compile-flags%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
As I said in the comment, I think you actually want to decide at runtime. But to answer the question you asked:
What it looks like you're doing is creating an abstract interface to any Vulkan window system, and putting different implementations of that interface into their own shared libraries. You have to name the libraries differently, e.g. libvkwsi-wayland.so, libvkwsi-xcb.so.
Usually, people will have a single executable that decides which implementation to use, and uses dlopen to load the corresponding shared library. You then need to use dlsym to get function pointers for functions in that library. If you're using C++ and the abstract interface is a literal abstract base class, then your shared libraries would have a single standalone function which creates and returns an instance of a class derived from that abstract class. The application would call that factory function, and from then on could just make virtual function calls into the object like normal.
If you want to directly link against the shared library ("-l" flag at executable link time), then you have to have a separate executable per window system (myapp-wayland, myapp-xcb, etc.). In that case, you'd probably also want to have a shell or python script that figures out which window system to use and then invokes the right executable -- that way your users don't need to know what window system they should use (fine for advanced users, not so much for most people).
Using separate executables means you're effectively distributing multiple copies of your entire application, even though nearly all of it is probably identical between window systems.
answered Nov 14 '18 at 4:02
Jesse HallJesse Hall
3,6821220
add a comment |
As I said in the comment, I think you actually want to decide at runtime. But to answer the question you asked:
What it looks like you're doing is creating an abstract interface to any Vulkan window system, and putting different implementations of that interface into their own shared libraries. You have to name the libraries differently, e.g. libvkwsi-wayland.so, libvkwsi-xcb.so.
Usually, people will have a single executable that decides which implementation to use, and uses dlopen to load the corresponding shared library. You then need to use dlsym to get function pointers for functions in that library. If you're using C++ and the abstract interface is a literal abstract base class, then your shared libraries would have a single standalone function which creates and returns an instance of a class derived from that abstract class. The application would call that factory function, and from then on could just make virtual function calls into the object like normal.
If you want to directly link against the shared library ("-l" flag at executable link time), then you have to have a separate executable per window system (myapp-wayland, myapp-xcb, etc.). In that case, you'd probably also want to have a shell or python script that figures out which window system to use and then invokes the right executable -- that way your users don't need to know what window system they should use (fine for advanced users, not so much for most people).
Using separate executables means you're effectively distributing multiple copies of your entire application, even though nearly all of it is probably identical between window systems.
answered Nov 14 '18 at 4:02
Jesse HallJesse Hall
3,6821220
add a comment |
As I said in the comment, I think you actually want to decide at runtime. But to answer the question you asked:
What it looks like you're doing is creating an abstract interface to any Vulkan window system, and putting different implementations of that interface into their own shared libraries. You have to name the libraries differently, e.g. libvkwsi-wayland.so, libvkwsi-xcb.so.
Usually, people will have a single executable that decides which implementation to use, and uses dlopen to load the corresponding shared library. You then need to use dlsym to get function pointers for functions in that library. If you're using C++ and the abstract interface is a literal abstract base class, then your shared libraries would have a single standalone function which creates and returns an instance of a class derived from that abstract class. The application would call that factory function, and from then on could just make virtual function calls into the object like normal.
If you want to directly link against the shared library ("-l" flag at executable link time), then you have to have a separate executable per window system (myapp-wayland, myapp-xcb, etc.). In that case, you'd probably also want to have a shell or python script that figures out which window system to use and then invokes the right executable -- that way your users don't need to know what window system they should use (fine for advanced users, not so much for most people).
Using separate executables means you're effectively distributing multiple copies of your entire application, even though nearly all of it is probably identical between window systems.
answered Nov 14 '18 at 4:02
Jesse HallJesse Hall
3,6821220
As I said in the comment, I think you actually want to decide at runtime. But to answer the question you asked:
What it looks like you're doing is creating an abstract interface to any Vulkan window system, and putting different implementations of that interface into their own shared libraries. You have to name the libraries differently, e.g. libvkwsi-wayland.so, libvkwsi-xcb.so.
Usually, people will have a single executable that decides which implementation to use, and uses dlopen to load the corresponding shared library. You then need to use dlsym to get function pointers for functions in that library. If you're using C++ and the abstract interface is a literal abstract base class, then your shared libraries would have a single standalone function which creates and returns an instance of a class derived from that abstract class. The application would call that factory function, and from then on could just make virtual function calls into the object like normal.
If you want to directly link against the shared library ("-l" flag at executable link time), then you have to have a separate executable per window system (myapp-wayland, myapp-xcb, etc.). In that case, you'd probably also want to have a shell or python script that figures out which window system to use and then invokes the right executable -- that way your users don't need to know what window system they should use (fine for advanced users, not so much for most people).
Using separate executables means you're effectively distributing multiple copies of your entire application, even though nearly all of it is probably identical between window systems.
answered Nov 14 '18 at 4:02
Jesse HallJesse Hall
3,6821220
answered Nov 14 '18 at 4:02
Jesse HallJesse Hall
3,6821220
answered Nov 14 '18 at 4:02
Jesse HallJesse Hall
3,6821220
answered Nov 14 '18 at 4:02
Jesse HallJesse Hall
3,6821220
3,6821220
add a comment |
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53292280%2fhow-to-handle-distributing-shared-libraries-with-different-compile-flags%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
2
Is there some reason why you can't just have both, and decide which API to use based on what's available on the user's system or by user settings? I'm not a Linux user, so I don't know much about this.
– Nicol Bolas
Nov 14 '18 at 2:29
1
Yes, I was considering this! That would mean I'd add #include headers for both APIs for the Linux build, would that be okay?
– coffeesaga
Nov 14 '18 at 2:35
1
Yes, including headers for both and deciding which to use at runtime and deciding which to use at runtime is fine and probably best if you're distributing binaries.
– Jesse Hall
Nov 14 '18 at 3:53