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 MarkThread Previous