Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow for the path to the perl installation to be specified #45

Closed
thomaseizinger opened this issue Dec 12, 2019 · 5 comments · Fixed by #49
Closed

Allow for the path to the perl installation to be specified #45

thomaseizinger opened this issue Dec 12, 2019 · 5 comments · Fixed by #49

Comments

@thomaseizinger
Copy link

Currently, the crate just runs perl which will use the first installation that is in the path.

This this not work on the windows-runner of GitHub actions and fails with the following error:

error: failed to run custom build command for `openssl-sys v0.9.53`

Caused by:
  process didn't exit successfully: `d:\a\create-comit-app\create-comit-app\target\debug\build\openssl-sys-5ec2b21008c71a01\build-script-main` (exit code: 101)
--- stdout
cargo:rustc-cfg=const_fn
running "perl" "./Configure" "--prefix=d:\\a\\create-comit-app\\create-comit-app\\target\\debug\\build\\openssl-sys-935999bfd09d3702\\out\\openssl-build\\install" "no-dso" "no-ssl3" "no-unit-test" "no-comp" "no-zlib" "no-zlib-dynamic" "no-engine" "no-async" "no-asm" "VC-WIN64A"
Configuring OpenSSL version 1.1.1d (0x1010104fL) for VC-WIN64A
Using os-specific seed configuration

--- stderr

******************************************************************************
This perl implementation doesn't produce Windows like paths (with backward
slash directory separators).  Please use an implementation that matches your
building platform.

This Perl version: 5.26.2 for x86_64-msys-thread-multi
******************************************************************************

Adding the already installed version of strawperryperl to the path fixes the issue.

However, it would be nice to have an environment variable that allows one to override the path to the Perl installation. This would make it more obvious, what we need the different Perl installation for.

I am thinking of an env variable like OPENSSL_SRC_PERL_HOME.

Thoughts?

@alexcrichton
Copy link
Owner

Sounds reasonable to me to add!

@sfackler
Copy link
Collaborator

I think PERL would be the standard name for the environment variable.

@thomaseizinger
Copy link
Author

I think PERL would be the standard name for the environment variable.

The idea behind a name like OPENSSL_SRC_PERL_HOME or maybe OPENSSL_SRC_PERL was to make it explicit that it is openssl that requires this specific perl installation.
In my case, openssl is a transitive dependency, deep down in the dependency tree and the command that I am actually executing is make release (which then calls cargo build with certain features).

I am not sure how important that actually is though :)

alexcrichton pushed a commit that referenced this issue Jan 10, 2020
* Allow to specify custom path for Perl

Env var OPENSSL_SRC_PERL can be set to specify
a path to the perl binary to use to call the openssl
perl scripts.

Resolves #45

* Fallback to PERL env var if OPENSSL_SRC_PERL is not set
neuronull added a commit to vectordotdev/openssl-src-rs that referenced this issue Jul 19, 2022
* only build necessary target (alexcrichton#43)

* Bump to 111.6.1+1.1.1d

* Update checkout actions reference

* Fixed apparent typo in the readme (alexcrichton#46)

* Work around upstream cargo issues

* Add handling for target riscv64gc-unknown-linux-gnu (alexcrichton#48)

* Disable asmjs for now

* Allow to specify custom path for Perl (alexcrichton#49)

* Allow to specify custom path for Perl

Env var OPENSSL_SRC_PERL can be set to specify
a path to the perl binary to use to call the openssl
perl scripts.

Resolves alexcrichton#45

* Fallback to PERL env var if OPENSSL_SRC_PERL is not set

* Add support for non-x86 archs on FreeBSD (alexcrichton#50)

Caused by:
  process didn't exit successfully: `.../rust-bootstrap/work-aarch64/rustc-1.40.0-src/build/x86_64-unknown-freebsd/stage1-tools/release/build/openssl-sys-4b2d35028bf73953/build-script-main` (exit code: 101)
--- stdout
cargo:rustc-cfg=const_fn

--- stderr
thread 'main' panicked at 'don't know how to configure OpenSSL for aarch64-unknown-freebsd', .../rust-bootstrap/work-aarch64/rustc-1.40.0-src/vendor/openssl-src/src/lib.rs:178:18

* Update CI installation of Rust on macos~

* support for illumos systems (alexcrichton#52)

Resolves alexcrichton#51

* More comment out of asmjs

* Use gmake by default on all DragonFlyBSD, FreeBSD or Solaris targets (alexcrichton#53)

* Bump to 1.1.1e (alexcrichton#54)

* Add support for illumos triple (alexcrichton#56)

* Bump to 1.1.1f (alexcrichton#58)

* Release 111.8.1+1.1.1f

* Bump to 1.1.1g

* Do not overwrite AR and RANLIB env vars if set (alexcrichton#62)

* Add engine support for linux-gnu (alexcrichton#63)

* add engine support for linux-gnu

Signed-off-by: Xintao <hunterlxt@live.com>

* address comment

Signed-off-by: Xintao <hunterlxt@live.com>

* add blacklist os

Signed-off-by: Xintao <hunterlxt@live.com>

* add blacklist os

Signed-off-by: Xintao <hunterlxt@live.com>

* To check CI build info

Signed-off-by: Xintao <hunterlxt@live.com>

* add comments

Signed-off-by: Xintao <hunterlxt@live.com>

* Bump to 111.10.0+1.1.1g

* Fix build on macOS with latest cc crate (alexcrichton#67)

cc v1.0.58 broke the macOS build by including the "-arch" flag in the
default set of compiler flags. Strip it out, like we do for iOS targets.

Closes alexcrichton#66.

* Bump to 111.10.1+1.1.1g

* add optional features for less used algorithms (alexcrichton#68)

This commit disables by default a few of the weaker cryptographical algorithms into
a "weak-crypto" feature as well as some of the less used algorithms into
their own specific features.
These algorithms are not directly exposed through the rust-openssl crate.
The compilation of these can be re-enabled by selecting the desired features.
This should slightly reduce build time and library size.

Signed-off-by: Petre Eftime <petre.eftime@gmail.com>

* Bump to 111.10.2+1.1.1g

* Bump to 1.1.1h (alexcrichton#73)

* Add FreeBSD powerpc64le support (alexcrichton#75)

FreeBSD PowerPC64LE is a new target.

This is needed to cross-build cargo.

* Add upstream patch to allow building on aarch64-apple-darwin (alexcrichton#74)

* Use fs module convenience methods for MUSL patch

* Add upstream patch to allow building on aarch64-apple-darwin

Closes alexcrichton#72

* i586 support (alexcrichton#76)

* Bump to 111.12.0+1.1.1h

* Add aarch64-apple-darwin to CI (alexcrichton#77)

* OpenBSD support (alexcrichton#78)

* Update OpenSSL to 1.1.1i

* Update CI

* Remove now no-longer-necessary patches

* Support targets `armv7-unknown-linux-gnueabi/musleabi` (alexcrichton#80)

Support targets `armv7-unknown-linux-gnueabi` & `armv7-unknown-linux-musleabi`

* Make it compile for wasm32-wasi (alexcrichton#81)

* Catch more failures on Windows in CI (alexcrichton#84)

* Catch more failures on Windows in CI

* Link missing library for OpenSSL on MSVC

Looks like some functions may pull in user32 functions, so that library
needs to be linked.

* Try to fix msvc +crt-static builds

* Try to see all failures

* More output

* Fix setting crt-static

* More CI tweaks

* Add the bin dir to cargo's search path on MSVC

That's where it contains the actual dlls needed at runtime

* Moved "no-shared" so that also windows statically link to the libraries (alexcrichton#83)

* Moved "no-shared" so that windows statically link to the libraries

* try reapplying changes

* removed shared as it's always false.

Co-authored-by: molleafauss <lmollea@yahoo.it>

* Bump to OpenSSL 1.1.1j (alexcrichton#85)

* add nasm support for msvc (alexcrichton#87)

* add nasm support for windows-msvc

This will automatically detect whether nasm.exe is installed and
try to enable the assembly language routines. These can also be
disabled by set the `OPENSSL_RUST_NO_NASM` environment variable to
a non-zero value.

* don't use '>> $GITHUB_ENV' to overwrite PATH

* remove the windows check in CI

* give user more control on the env var

* add env var in CI, less acceptable values for env var

* fix path format for using bash on windows

* 'OPENSSL_RUST_USE_NASM' env var only accept 0 or 1

* Bump to 1.1.1k

* Add FreeBSD powerpc support (alexcrichton#90)

This is needed to support cargo cross-build for 32-bit powerpc on FreeBSD.

* Upgrade to GitHub-native Dependabot (alexcrichton#92)

Co-authored-by: dependabot-preview[bot] <27856297+dependabot-preview[bot]@users.noreply.github.com>

* Support targets `armv5te-unknown-linux-gnueabi/musleabi` (alexcrichton#94)

* Support targets `popwerpc64(le)-unknown-linux-musl` (alexcrichton#95)

* Support targets `mips64(el)-unknown-linux-muslabi64` (alexcrichton#96)

* Support target `s390x-unknown-linux-musl` (alexcrichton#97)

* Bump to openssl 1.1.1l (alexcrichton#100)

* Bump to 1.1.1m

* test on 1.1.1 branch

* Fix aarch64-apple-darwin CI (alexcrichton#116)

(cherry picked from commit 466ffd2)

* Bump to 1.1.1n (alexcrichton#123)

* Update "old" windows image on CI (alexcrichton#126)

* Bump to 1.1.1o (alexcrichton#136)

* Bump to 1.1.1o

* Disable arm-linux-androideabi test

* Backport wycheproof exclude to 1.1.1 branch (alexcrichton#139)

* Backport wycheproof exclude to 1.1.1 branch

* Backport exclude CI checks

* Backport exclude CI checks

* Configure `--openssldir` to its default location (alexcrichton#141) (alexcrichton#142)

As pointed out in alexcrichton#140 otherwise certificates and configure is by
default looked up in the directory of the build machine itself which is
often a writable path. Instead switch the configuration option back to
the default recommended in openssl's `INSTALL.md`

Closes alexcrichton#140

* Bump to 111.20.0+1.1.1o (alexcrichton#143)

* Bump to 1.1.1p (alexcrichton#145)

* Bump to 1.1.1q (alexcrichton#147)

Co-authored-by: Jay <BusyJay@users.noreply.github.com>
Co-authored-by: Alex Crichton <alex@alexcrichton.com>
Co-authored-by: Alex Gaynor <alex.gaynor@gmail.com>
Co-authored-by: msizanoen1 <55322658+msizanoen1@users.noreply.github.com>
Co-authored-by: Franck Royer <royer.franck@gmail.com>
Co-authored-by: Tobias Kortkamp <t6@users.noreply.github.com>
Co-authored-by: Joshua M. Clulow <josh@sysmgr.org>
Co-authored-by: MikaelUrankar <49529234+MikaelUrankar@users.noreply.github.com>
Co-authored-by: Steven Fackler <sfackler@gmail.com>
Co-authored-by: Patrick Mooney <pmooney@pfmooney.com>
Co-authored-by: Steven Fackler <sfackler@palantir.com>
Co-authored-by: James McMurray <jamesmcm03@gmail.com>
Co-authored-by: Xintao <hunterlxt@live.com>
Co-authored-by: Nikhil Benesch <nikhil.benesch@gmail.com>
Co-authored-by: petreeftime <petre.eftime@gmail.com>
Co-authored-by: Brandon Bergren <git@bdragon.rtk0.net>
Co-authored-by: Jake Goulding <shepmaster@mac.com>
Co-authored-by: Will <will@mon.im>
Co-authored-by: Jake Goulding <jake.goulding@gmail.com>
Co-authored-by: kiron1 <kiron1@gmail.com>
Co-authored-by: IceCodeNew <32576256+IceCodeNew@users.noreply.github.com>
Co-authored-by: Pierre Krieger <pierre.krieger1708@gmail.com>
Co-authored-by: Alex Malgaroli <alex.malgaroli@gmail.com>
Co-authored-by: molleafauss <lmollea@yahoo.it>
Co-authored-by: Kane <KaneGreen@users.noreply.github.com>
Co-authored-by: Brandon Bergren <bdragon@FreeBSD.org>
Co-authored-by: dependabot-preview[bot] <27856297+dependabot-preview[bot]@users.noreply.github.com>
Co-authored-by: messense <messense@icloud.com>
Co-authored-by: Alexis Mousset <contact@amousset.me>
Co-authored-by: Eric Huss <eric@huss.org>
Co-authored-by: Alexis Mousset <alexis.mousset@rudder.io>
@Sytten
Copy link

Sytten commented Sep 27, 2022

For the sake of other people (including myself) what is the path of the strawberry perl?
@thomaseizinger

EDIT: The PR contains the code so:

 - name: Use strawberry perl
      if: startsWith(matrix.os, 'windows')
      run: echo ::set-env name=OPENSSL_SRC_PERL::C:/Strawberry/perl/bin/perl
      shell: bash

@thomaseizinger
Copy link
Author

@Sytten Last time I used it (3 years ago), it was C:/strawberry/perl/bin/perl.exe.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants