It seems the perl itself is broken and the core perl dynaloader fails to work, if the perl was started with long names. For example, running slic3r with the following slic3r.bat fails:
"%~dp0\perl5.24.0.exe" "%~dp0\slic3r.pl" %* It works though, if one replaces the magic %~dp0 with %~dps0: "%~dps0\perl5.24.0.exe" "%~dps0\slic3r.pl" %* That way both the paths of the perl.exe and slic3r.pl use the 8.3 characters only per directory entry. For the reference, this is the original github issue: https://github.com/prusa3d/Slic3r/issues/133 I think this may be interesting to some, but it seems not to be a wxPerl issue per se, so I think I will stop rumbling about it here :-) On Thu, Feb 16, 2017 at 4:55 PM, bubnikv . <bubn...@gmail.com> wrote: > I analyzed the crash further. It is sufficient to load any of the > following modules to get perl crashing, when the perl is installed in a > folder with local characters: > > use Wx::DND; > use Wx::GLCanvas; > use Wx::GLCanvas qw(:all); > use Wx::Grid; > use Wx::Html; > use Wx::Print; > > > On Thu, Feb 16, 2017 at 2:42 PM, bubnikv . <bubn...@gmail.com> wrote: > >> Hello. >> >> I am supporting and ehancing a fork of Slic3r, one of the main >> applications for fused filamet 3D printing. >> http://slic3r.org/ >> https://github.com/prusa3d/Slic3r/releases >> >> It is likely one of the largest wxPerl applications, combining perl, >> wxWidgets and a lot of custom C++ code. >> >> Our customers have currently issues running Slic3r on Windows, when >> installed into a path with localized characters, for example Russian. This >> often happens if one installs Slic3r into his home directory. >> >> I verified that wxPerl outright crashes, when installed into a localized >> directory on Windows 10 64bit and Strawberry Perl 5.24.0, tested with >> wxdemo. >> >> Is there a chance that this will be looked into by someone, please? Or >> has been wxPerl abandoned and I am left to provide a fix myself? >> >> Thanks, >> Vojtech >> >> >
