perl issue when building on windows #2149
Comments
|
|
According to our CI, it is up to date when running |
|
The issue is when you're building on windows using The giveaway was the Linux uses Instead, you want the Windows perl. The - name: Set Perl environment variables
if: runner.os == 'Windows'
run: |
echo "PERL=$((where.exe perl)[0])" | Out-File -FilePath $env:GITHUB_ENV -Append -Encoding utf8
echo "OPENSSL_SRC_PERL=$((where.exe perl)[0])" | Out-File -FilePath $env:GITHUB_ENV -Append -Encoding utf8The trick is to not specify
Hope this helps :) |
See sfackler/rust-openssl#2149. Apparently, in the Windows runner, commands executed in a `run` block will use the version of Perl built into MinGW instead of the one installed in the system, which breaks the openssl build because one of the expected Perl modules can't be found. There are different ways to fix this. The one suggested in this PR is returning back to using the cargo action for "normal" (not cross compilation) builds like it used to work before. My understanding is that it helps by running cargo directly as opposed to running it from Bash. Alternatively, we could bypass the corresponding build steps in openssl by providing locations of openssl source code via environment variables like it is suggested in the rust-openssl issue linked above.
See sfackler/rust-openssl#2149. Apparently, in the Windows runner, commands executed in a `run` block will use the version of Perl built into MinGW instead of the one installed in the system, which breaks the openssl build because one of the expected Perl modules can't be found. There are different ways to fix this. The one suggested in this PR is returning back to using the cargo action for "normal" (not cross compilation) builds like it used to work before. My understanding is that it helps by running cargo directly as opposed to running it from Bash. Alternatively, we could bypass the corresponding build steps in openssl by providing locations of openssl source code via environment variables like it is suggested in the rust-openssl issue linked above.
See sfackler/rust-openssl#2149. Apparently, in the Windows runner, commands executed in a `run` block will use the version of Perl built into MinGW instead of the one installed in the system, which breaks the openssl build because one of the expected Perl modules can't be found. There are different ways to fix this. The one suggested in this PR is returning back to using the cargo action for "normal" (not cross compilation) builds like it used to work before. My understanding is that it helps by running cargo directly as opposed to running it from Bash. Alternatively, we could bypass the corresponding build steps in openssl by providing locations of openssl source code via environment variables like it is suggested in the rust-openssl issue linked above.
See sfackler/rust-openssl#2149. Apparently, in the Windows runner, commands executed in a `run` block will use the version of Perl built into MinGW instead of the one installed in the system, which breaks the openssl build because one of the expected Perl modules can't be found. There are different ways to fix this. The one suggested in this PR is returning back to using the cargo action for "normal" (not cross compilation) builds like it used to work before. My understanding is that it helps by running cargo directly as opposed to running it from Bash. Alternatively, we could bypass the corresponding build steps in openssl by providing locations of openssl source code via environment variables like it is suggested in the rust-openssl issue linked above.
See sfackler/rust-openssl#2149. Apparently, in the Windows runner, commands executed in a `run` block will use the version of Perl built into MinGW instead of the one installed in the system, which breaks the openssl build because one of the expected Perl modules can't be found. There are different ways to fix this. The one suggested in this PR is returning back to using the cargo action for "normal" (not cross compilation) builds like it used to work before. My understanding is that it helps by running cargo directly as opposed to running it from Bash. Alternatively, we could bypass the corresponding build steps in openssl by providing locations of openssl source code via environment variables like it is suggested in the rust-openssl issue linked above.
See sfackler/rust-openssl#2149. Apparently, in the Windows runner, commands executed in a `run` block will use the version of Perl built into MinGW instead of the one installed in the system, which breaks the openssl build because one of the expected Perl modules can't be found. There are different ways to fix this. The one suggested in this PR is returning back to using the cargo action for "normal" (not cross compilation) builds like it used to work before. My understanding is that it helps by running cargo directly as opposed to running it from Bash. Alternatively, we could bypass the corresponding build steps in openssl by providing locations of openssl source code via environment variables like it is suggested in the rust-openssl issue linked above.
Hi, we are trying to build a Rust project having indirect dependencies to openssl-sys.
When building on
Microsoft Windows Server 2022(github runner), we get the following perl error:I tried to setup Perl in the workflow before rust build
But it does not fix the issue.
Any help would be appreciated.
The text was updated successfully, but these errors were encountered: