PAR::Heavy::_dl_findfile searches only for mangled DLL names when using cache dir #11
Comments
|
@shawnlaffan I restructured _extract_inc() in I added a test ( |
|
Thanks @rschupp - that seems to do the trick on my system. There is still the issue of Glib.xs.dll, Pango.xs.dll, Cairo.xs.dll and Gtk2.xs.dll finding the paths to each other but that would require special-case code to add their directories to |
Upstream changes: 1.063 2024-03-15 - Fixes #86 "-l somelib.dll doesn't work in recent PAR::Packer versions" par_setup_libpath() in myldr/mktmpdir.c used to set all known "search path for DLLs" environment variables (e.g. LD_LIBRARY_PATH on Linux). The search path is set up so that the first directory searched is a packed executable's cache directory (where the shared perl library will be extracted to, also all packed "external" DLLs). In 2017 (by 2ac7078) it was changed to only set the variable relevant for the OS where PAR::Packer was build on, given by $Config{ldlibpthname}. But some perl distributions (e.g. Strawberry on Windows) do not specify $Config{ldlibpthname}. Hardwire "PATH" for MSWin32 and otherwise complain if this Config variable is undefined. Add t/85-ldlibpthname.t: check that the value of the environment variable for searching for DLLs, usually $ENV{$Config{ldlibpthname}}, starts with the cache directory, $ENV{PAR_TEMP}. - Skip t/87-xs-cross.t if ExtUtils::Depends 0.8001 is installed. This version fails to build and install the "import lib" corresponding to XSQuux.xs.dll and hence fails to build XSBar.xs.dll. The test works on GitHub CI, because the "strawberry" perl distribution installed there comes with ExtUtils::Depends version 0.8000 (ie. **not** current) pre-installed. 1.062 2024-03-05 - Fix #84: PAR::Packer packaged scripts lose the ability to parse UTF-8 arguments from the command line myldr/boot.c passes its arguments in argv (except argv[0]) down to the custom perl interpreter using _spawnvp(). But this argv has already been converted to the local code page, so the custom interpreter can't get it back using GetCommandLineW(). Convert myldr/boot.c to use GetCommandLineW() and CommandLineToArgvW() to get the "real" (UTF-16) command line and pass that down via _wspawnvp(). Convert shell_quote() (to escape embedded blanks, double quotes etc in the arguments) from using char to wchar_t. Thanks to @fengzyf for the report and most of the work. - pod: explain how REGEX is applied in "--modfilter=FILTER=REGEX" - require PAR >= 1.020 - add new test t/87-xs-cross.t to investigate rschupp/PAR#11 - move some test modules around and fix up tests accordingly - bump version of actions/checkout
Unfortunately it seems I did not properly test the change made in 7626a9c
That change uses the non-mangled DLL name only when first unzipping the archive. Subsequent calls using the cache dir still use the mangled name and hence Gtk2, Cairo, Pango and Glib all hit issues when loading their dlls on Windows.
Previous discussion is under #8
My current workaround is to always check if the target exists under
$ENV{PAR_TEMP}/inc: shawnlaffan@64b5eacThis works except that it is necessary to add the
lib/auto/Gtk2,lib/auto/Cairoetc dirs to the path before anyuse Gtk2call.Maybe there is an additional change that can be applied to PAR::Heavy, but I'm not sure where.
The text was updated successfully, but these errors were encountered: