Hello!
I'm trying to figure out the best way to go around distributing wxWidgets as a shared library with my application in Linux (starting with Ubuntu). The reason I can't simply have wxWidgets as a dependency for users to install is that I had to make some custom changes to wxWidgets, so I have to distribute the shared library I built.
In Windows I simply created static builds of wxWidgets and in OSX I included the shared library with the app bundle, but it doesn't look like that's a viable path under Linux.
I was able to build my application using the rpath and ORIGIN settings/flags, so that that when running it, it searches for the libraries in my binary's directory. Now the library is found, however upon running I get the error "symbol XXXXXX version WXU_3.1 not defined in file XXXXX with link time reference"
Obviously, I'm doing something wrong and I may be going about this the completely wrong way.
I appreciate any suggestions.
Thank you!
- Alejandro
wxWidgets Shared Library and Linux
wxWidgets Shared Library and Linux
Last edited by gul_garak on Mon Jul 29, 2019 7:40 pm, edited 1 time in total.
Re: wxWidgets Shared Library and Linux
Hi,
It's unusual to need to create wx static builds on linux, but it's perfectly possible. Just add
--disable-shared
to your configure options.
You might also like to build in a subdir of the wx source, passing
--prefix=$(pwd)
to configure. You will then create a build that can be accessed direct from that subdir (just point to it in your terminal's $PATH, or add it to your IDE's compiler/linker settings). This avoids conflict with your system wx.
Regards,
David
It's unusual to need to create wx static builds on linux, but it's perfectly possible. Just add
--disable-shared
to your configure options.
You might also like to build in a subdir of the wx source, passing
--prefix=$(pwd)
to configure. You will then create a build that can be accessed direct from that subdir (just point to it in your terminal's $PATH, or add it to your IDE's compiler/linker settings). This avoids conflict with your system wx.
Regards,
David
Re: wxWidgets Shared Library and Linux
Thank you for the reply!
When I searched the forums the consensus was that linking to wxWidgets statically was a bad idea because wxWidgets dependencies would be linked statically. That would make it difficult dealing with different distributions and versions, and I saw mention of licensing concerns because of some of those dependencies.
Not sure what's the better path to follow.
Thank you!
- Alejandro
Re: wxWidgets Shared Library and Linux
Hi,
What type of custom changes did you do?
Why not submit them as a patch to wxWidgets so that it will be included? Or if they are specific to your application - why not create a child class{es} and update them with you modifications?
But the easiest solution of all is to build static libraries as DavidHart pointed out.
Thank you.
What type of custom changes did you do?
Why not submit them as a patch to wxWidgets so that it will be included? Or if they are specific to your application - why not create a child class{es} and update them with you modifications?
But the easiest solution of all is to build static libraries as DavidHart pointed out.
Thank you.
Re: wxWidgets Shared Library and Linux
Indeed, but that applies to your program anyway, even if dynamically-linked to your distro's wx package(s).When I searched the forums the consensus was that linking to wxWidgets statically was a bad idea because wxWidgets dependencies would be linked statically. That would make it difficult dealing with different distributions and versions, and I saw mention of licensing concerns because of some of those dependencies.
A very simple, self-contained program might run on most or all distros/distro-versions, but anything more complex very likely won't; e.g. a program built on debian 9 might run on a ubuntu of a similar age, but is highly unlikely to run on fedora or opensuse, or even a much earlier debian.
Which is why distros supply packages from package managers. Or, more recently, why Flatpaks and such exist.
Re: wxWidgets Shared Library and Linux
We did create new classes for most of our changes that are part of our app, but some of it were bug fixes or changes that I couldn't simply do overriding the base classes (some of it was to allow for a "dark mode" for our app, some simply because I needed to build with different #defines than the default).
I've been hoping to submit some of the changes (particularly the bug fixes..) once I clean them up.
Thank you!
Re: wxWidgets Shared Library and Linux
Thank you both for the replies so far!
I was able to (properly this time) set the rpath for my binary so that it finds our custom wxWidgets libs included with the app. So I think that's a viable solution. As you pointed out I will still need to build for distros that are very different, but this way I shouldn't be locked in to the dependencies that were present in my system at the time.
Over the next few weeks we'll experiment with both dynamic and static builds of wxWidgets and see if we need to switch. I'll update this thread if we end up finding a reason to switch away from including our custom wxWidgets so with the app.
Thank you again!
- Alejandro
I was able to (properly this time) set the rpath for my binary so that it finds our custom wxWidgets libs included with the app. So I think that's a viable solution. As you pointed out I will still need to build for distros that are very different, but this way I shouldn't be locked in to the dependencies that were present in my system at the time.
Over the next few weeks we'll experiment with both dynamic and static builds of wxWidgets and see if we need to switch. I'll update this thread if we end up finding a reason to switch away from including our custom wxWidgets so with the app.
Thank you again!
- Alejandro
Re: wxWidgets Shared Library and Linux
Hi,
Like I said, depending on how extensive the changes are - you can submit them as a patch to be included in wxWidgets itself, so you won't have that issue anymore, or just derive your own classes from the one you modified and place them in your project, calling base class functions when needed.
Thank you.
Like I said, depending on how extensive the changes are - you can submit them as a patch to be included in wxWidgets itself, so you won't have that issue anymore, or just derive your own classes from the one you modified and place them in your project, calling base class functions when needed.
Thank you.