legacy.dll not copied
NieLuc opened this issue · comments
-
I'm submitting a:
- Vulnerability report -> use the specific form instead!
- Bug report
- Feature request/suggestion
-
[Bug report] What is the current behavior?
-
When I execute my application on my dev machine, all is working. When I deploy this app on my target machine, I get an error "The application was unable to start correctly (0xc0000142)".
The openSSL libcrypto-3-x64.dll library rely on legacy.dll, which seems to be linked with the absolute path of my vcpkg installation on my development computer (DW give me the exact path of legacy.dll on my dev computer) ! If I recreate on my target computer the exact path of legacy.dll on my development computer, my app run !
-
[Bug report] What is the expected behavior?
Library gets copied into the build folder and project is linked to this library -
[Bug report] Please provide the steps to reproduce and if possible a minimal reproduction code of the problem
Try to deploy podofo on a Computer without vcpkg installed. -
Please tell us about your environment:
- Version/git revision: [1.10.0]
- Operating System: Windows (64 bits)
- Package manager used: vcpkg
I dont know if this error is based on the podofo cmake configuration or is within vcpkg.
Encountered similar problem with vcpkg installation.
As a workaround try to set OPENSSL_MODULES environment variable like here:
docwire/docwire@b3a04e4
legacy.dll is installed via openssl vcpkg port that is required by podofo vcpkg port, but it is inside ossl-modules subdirectory so it can be invisible according to $PATH (on Windows) or $LD_LIBRARY_PATH (on Linux).
Podofo is loading legacy.dll dynamically via openssl function call, at least last time I checked.
The OPENSSL_MODULES path is the path to the OPENSSL libs installed via vcpkg in my case "C:\vcpkg\packages\openssl_x64-windows\bin"? Or does this dictate the path where to install the OPENSSL_MODULES?
PoDoDo specify its dependency to OpenSSL on the CMakeLists.txt by the following few directives:
find_package(OpenSSL REQUIRED)
# ...
set(PODOFO_LIB_DEPENDS OpenSSL::SSL)
Unless there is a better way to specify that PoDoFo needs the legacy providers (and it doesn't appear there's one at the moment), the issue you have is with deployment of vcpkg dependencies.
The OPENSSL_MODULES path is the path to the OPENSSL libs installed via vcpkg?
It seems a OpenSSL project specific runtime setting, so I guess yes. There may be some vcpkg settings so that the modules are copied among the main OpenSSL runtime components, but I don't use vcpkg so I don't know. You may have scripts to fix the deployment of the dependencies as part of your development workflow, which is also a common practice when things don't work out of the box. If you think there's a way where PoDoFo or OpenSSL vcpkg ports could be improved please refer to the vcpkg project as I don't have control on them, but feel free to continue the discussion here for workarounds.
The OPENSSL_MODULES path is the path to the OPENSSL libs installed via vcpkg in my case "C:\vcpkg\packages\openssl_x64-windows\bin"? Or does this dictate the path where to install the OPENSSL_MODULES?
Its the environment variable that is used by openssl during loading of modules (in runtime). Set this to location where there really are located before, before you run the application. You can just search for legacy.dll and check correct path.
This is the initial discussion about this issue on vcpkg website:
microsoft/vcpkg#36715
You can join, maybe someone have better solution.
Tbh honest im too stupid to Implement your solution, can you give me a step by step manual for dummies?
I can see now that your problem might be closely related but not exactly the similar. You can try to set OPENSSL_MODULES environment variable to path where the legacy.dll is stored and then run the problematic application but if absolute path is embedded into libcrypto.dll I am not sure if it will help.
Okay, now this works for me. But I dont like to set environment variables on my target machine at least not permanent. Is there a way to build it so that you dont have to do that?
I guess today RC4 is not that required, so I stopped eagerly throwing on missing RC4. See fb36f86.
Great, very good decision in my opinion. Missing legacy.dll should stop processing only if it's really required.