Hi, On 22/02/2013 12:32, Smylers wrote:
If I compile Wx using Strawberry 5.14.3, should that module then work if deployed to something still on 5.14.2.1?
I think you may encounter problems. I'm almost certain that the libgcc and libstdc++ that your Wx/wxWidgets will need to load cannot coexist in the same process with the libgcc that your Perl will have loaded. You could try, but I would expect it to fail.
Smylers [*1] Ironically I chose Dwim Perl over Strawberry was because it comes with Wx, so I thought that would make life simpler. Unfortunately wxWidgets 2.8 has some regressions in terms of user interface behaviour when compared with the ancient version people were using, so it turns out I don't want to use the Wx that comes with Dwim Perl anyway ...
You could check with Gabor when he intends the next release of Dwim Perl. I imagine he will wait for Perl / Strawberry 5.18 at this point in time.
If you have many users, and you are happy compiling your own wxWidgets / Wx, I would recommend distributing them using PAR::Dist; On Windows, creating a PAR distribution is a 1-liner, as is the installation command for end users. Of course, you'd have to switch to a different release of Strawberry.
A final possibility - you may be able to fix your issues with the 2.8 version of wxWidgets. What are the issues you have exactly? For example, the default build with Alien::wxWidgets includes version 2.6 compatibility, but you can switch that off at compile time.
Regards Mark
