@lexming Fails for me with:

$ eb --from-pr 12858 --include-easyblocks-from-pr 2429
...
ERROR: Traceback (most recent call last):
  File "/data/gent/400/vsc40023/easybuild_easy_installed/lib/python2.7/site-packages/easybuild_framework-4.3.5.dev0-py2.7.egg/easybuild/main.py", line 117, in build_and_install_software
    (ec_res['success'], app_log, err) = build_and_install_one(ec, init_env)
  File "/data/gent/400/vsc40023/easybuild_easy_installed/lib/python2.7/site-packages/easybuild_framework-4.3.5.dev0-py2.7.egg/easybuild/framework/easyblock.py", line 3371, in build_and_install_one
    app = app_class(ecdict['ec'])
  File "/tmp/eb-wb7k98av/included-easyblocks-u3uhdwkv/easybuild/easyblocks/openssl_wrapper.py", line 132, in __init__
    os.path.join(lib_dir, self.openssl_engines[self.version]),
  File "/usr/lib64/python3.6/posixpath.py", line 94, in join
    genericpath._check_arg_types('join', a, *p)
  File "/usr/lib64/python3.6/genericpath.py", line 151, in _check_arg_types
    raise TypeError("Can't mix strings and bytes in path components") from None
TypeError: Can't mix strings and bytes in path components

Let's see if a close/re-open wakes up GitHub Actions...

Soo.. do we not want this to find the CentOS7 openssl11 packages? Because they are intentionally not installed into a standard path, since that would break the rest of the system?

Soo.. do we not want this to find the CentOS7 openssl11 packages? Because they are intentionally not installed into a standard path, since that would break the rest of the system?

We could enhance this easyblock to make sure those are found too, but you would need to specify where to find them of course (and we could include the CentOS 7 location as a default in the easyblock)?

Right, well, I'm not sure how to really suggest adding those paths, and, it's pretty much a mix here. We've got

1. /usr/bin/openssl11
2. /usr/lib64/openssl11/ (or /usr/lib64/libssl.so.1.1)
3. /usr/include/openssl11/
   So, optional system_ssl_binary, system_ssl_libpath, ssl_ssl_includepath? I think it's preferable for these to be set by default on centos/rhel 7 systems since it would be to easy to miss for a large portion or users.

Also, the automatic fallback method here; there isn't a practical way to update ever update it without having to revert to a live rebuild (ouch)? (as opposed to the more atomic change like with Java and modulerc)

@Micket hardcoding paths into the easyblock should not be necessary. If the host system is configured to use OpenSSL 1.1 then the libs and headers will be found. If OpenSSL 1.1 is not part of the environment, we should never link to it by default. I don't want EB to catch any rogue .so in my system. In my opinion, all we can do to cover that case is to provide an extra option so that the user can manually add extra paths to be checked by the easyblock.

Regarding the fallback method, a modulerc is not an option because it does not preserve the paths to the libraries. It automatically re-loads the real OpenSSL module, so paths to libs change accordingly. In case of an upgrade of OpenSSL, the process is actually simpler with this wrapper as you only have to rebuild the wrapper with the new version, instead of installing the new OpenSSL version + updating the modulerc.

I always considered rebuilding to be the worst case scenario, especially for a common dependency, as it means a large section of software is going to break for over a minute during rebuilds (assuming the new build even succeeds).
(A wrapper that symlinks to existing EB installs could work to minimize this, though somewhat messier (and impractical here))

But I really think we should automatically symlink to EPEL7s openssl11/openssl11-devel if present by default. In fact, that has been my only goal from all along, and what I think should be the recommended approach for all centos7 users. The only non-standard thing is an alternative include path and binary name (since there are 2 OS versions). The library itself is found in the standard paths (/usr/lib64/libssl.so.1.1)

With the addition of multiple library names per system/version, I moved the code loading and finding the library to its own function in systemtools. See easybuilders/easybuild-framework#3683

@lexming Another crash when OpenSSL-1.0.eb is being built from source after your last update:

ERROR: Traceback (most recent call last):
  File "/home/centos/easybuild/easybuild-framework/easybuild/main.py", line 117, in build_and_install_software
    (ec_res['success'], app_log, err) = build_and_install_one(ec, init_env)
  File "/home/centos/easybuild/easybuild-framework/easybuild/framework/easyblock.py", line 3571, in build_and_install_one
    result = app.run_all_steps(run_test_cases=run_test_cases)
  File "/home/centos/easybuild/easybuild-framework/easybuild/framework/easyblock.py", line 3465, in run_all_steps
    self.run_step(step_name, step_methods)
  File "/home/centos/easybuild/easybuild-framework/easybuild/framework/easyblock.py", line 3320, in run_step
    step_method(self)()
  File "/tmp/eb-t7009csl/included-easyblocks-lj9yuliv/easybuild/easyblocks/openssl_wrapper.py", line 252, in sanity_check_step
    ssl_files.extend(os.path.join('lib', libso) for libso in self.openssl_libs)
  File "/tmp/eb-t7009csl/included-easyblocks-lj9yuliv/easybuild/easyblocks/openssl_wrapper.py", line 252, in <genexpr>
    ssl_files.extend(os.path.join('lib', libso) for libso in self.openssl_libs)
  File "/usr/lib64/python3.6/posixpath.py", line 94, in join
    genericpath._check_arg_types('join', a, *p)
  File "/usr/lib64/python3.6/genericpath.py", line 149, in _check_arg_types
    (funcname, s.__class__.__name__)) from None
TypeError: join() argument must be str or bytes, not 'list'

@boegel will you stop breaking it? I'll have to ban your username from this easyblock...

In fact, I introduced this bug in my last commit. I'll make a better fix 👍

@boegel fixed in fd425a2. I replaced the changing list of OpenSSL libraries in self.openssl_libs into two separate variables, where the target libraries of the installation are always held in a simple list (self.target_ssl_libs). This fixes the last two errors.

I repeated all my previous tests and they are good.

Tested extensively with easybuilders/easybuild-easyconfigs#12858 across a range of different systems, operating systems, and CPU architectures.

@lexming: Thanks a lot for your efforts on this!