Conversation
The testsuite invokes many openssl commands using the shlib_wrap.sh script. It used to be possible to copy those commands for testing them standalone or run them in the debugger (see also description of issue openssl#10628). With providers this did not work anymore, because the script did not set the `OPENSSL_MODULES` and `OPENSSL_ENGINES` environment variables, they were already set by the `_tests` make target. To make `shlib_wrap.sh` self-contained again, we set the `OPENSSL_MODULES` and `OPENSSL_ENGINES` environment variables if they are unset. In fact, that's just what `opensslwrap.sh` already does.
|
|
||
| if [ -d "${HERE}../engines" -a "x$OPENSSL_ENGINES" = "x" ]; then | ||
| OPENSSL_ENGINES="${HERE}../engines"; export OPENSSL_ENGINES | ||
| if [ -z "$OPENSSL_ENGINES" ] && [ -d "${HERE}/engines" ] ; then |
There was a problem hiding this comment.
What's wrong with -a? Is there a reason you want to create two processes when one can be enough?
There was a problem hiding this comment.
Isn't it builtin anyway? The reason I changed it can be found in the TEST(1) manpage:
NOTE: Binary -a and -o are inherently ambiguous. Use 'test EXPR1 &&
test EXPR2' or 'test EXPR1 || test EXPR2' instead.
There was a problem hiding this comment.
IIRC, the -a evaluates both expressions, no?
| fi | ||
| if [ -z "$OPENSSL_MODULES" ] && [ -d "${THERE}/providers" ] ; then | ||
| OPENSSL_MODULES="${THERE}/providers"; export OPENSSL_MODULES | ||
| fi |
There was a problem hiding this comment.
I would rather not at this level. What if I want to test a newly built test program against the default config file?
There was a problem hiding this comment.
Hmmm... too bad. It was such a convenient way to plug in the debugger into a test command. Do you have a better suggestion how to fix it?
There was a problem hiding this comment.
The variables could be set explicitly on the command line instead of implicitly by the _test target, but that is not really a satisfying solution either.
There was a problem hiding this comment.
I don't see much inconvenience with this
OPENSSL_MODULES=providers ./util/shlib_wrap.sh gdb test/evp_extra_test
There was a problem hiding this comment.
Often it's more like
OPENSSL_MODULES=../../providers ../../util/shlib_wrap.sh gdb ../../apps/openssl ...
I don't see much inconvenience with this
You mean inconvenience to add it manually, or inconvenience to add it to the test output?
There was a problem hiding this comment.
...sets OPENSSL_MODULES and OPENSSL_ENGINES automatically...
...if unset...
There was a problem hiding this comment.
I view plug-ins (which our providers and engines are) as something different than shared libraries, even if the technology is the same. The difference is build-time linking vs run-time linking.
There was a problem hiding this comment.
I have an alternative idea that you might suitable, if you can have a little bit of patience? PR coming up.
There was a problem hiding this comment.
Sure. Surprise me... ;-)
There was a problem hiding this comment.
Have a look at #11110, I believe it fulfils what you want.
|
Closing in favour of #11110. |
Two commits:
shlib_wrap.sh: add module and engine paths to environment if unset
The testsuite invokes many openssl commands using the shlib_wrap.sh script.
It used to be possible to copy those commands for testing them standalone
or run them in the debugger (see also description of issue #10628).
With providers this did not work anymore, because the script did not
set the
OPENSSL_MODULESandOPENSSL_ENGINESenvironment variables,they were already set by the
_testsmake target.To make
shlib_wrap.shself-contained again, we set theOPENSSL_MODULESand
OPENSSL_ENGINESenvironment variables if they are unset. In fact,that's just what
opensslwrap.shalready does.opensslwrap.sh: make implementation more consistent with shlib_wrap.sh