GNOME Bugzilla – Bug 794830
openssl: issues with git
Last modified: 2018-05-04 15:17:43 UTC
Once openssl is built in cerbero, it causes issues with (system-wide) git on some distributions (in my case fedora). Steps to reproduce (on a clean checkout with no prefetched sources): ./cerbero-uninstalled bootstrap ./cerbero-uninstalled build openssl ./cerbero-uninstalled build libvpx Building the following recipes: libvpx [(1/1) libvpx -> fetch ] Running command 'mkdir -p /home/bilboed/work/devel/1.0/cerbero/build/sources/local/libvpx' Running command 'git init' Initialized empty Git repository in /home/bilboed/work/devel/1.0/cerbero/build/sources/local/libvpx/.git/ Running command 'git config user.email' bilboed@bilboed.com Running command 'git config user.name' Edward Hervey Running command 'git remote add origin https://github.com/webmproject/libvpx.git' Running command 'git fetch --all' Fetching origin fatal: unable to access 'https://github.com/webmproject/libvpx.git/': failed setting cipher list: PROFILE=SYSTEM error: Could not fetch origin Running command 'git reset --hard v1.6.0' fatal: ambiguous argument 'v1.6.0': unknown revision or path not in the working tree. Use '--' to separate paths from revisions, like this: 'git <command> [<revision>...] -- [<file>...]' The issue is "fatal: unable to access 'https://github.com/webmproject/libvpx.git/': failed setting cipher list: PROFILE=SYSTEM"
Note : this *might* be related to fedora's policy system (which is why it doesn't fail on debian) : https://fedoraproject.org/wiki/Changes/CryptoPolicy
But that means we run git in the same env we build, so git ends up linked against what we just built. That's not ideal ... I bet this is only an issue for non-cross-compiling cases ?
I thought I already fixed this. If not, we can enable more algos/ciphers. commit 24b0f9c21fa752fcbf0fe550859961155a6a8781 Author: Nirbheek Chauhan <nirbheek@centricular.com> Date: Fri Mar 9 01:41:18 2018 +0530 openssl.recipe: Enable more crypto algos on Linux These are not used by us, but the system version of Sphinx used by gst-validate ends up trying to use libssl built by this recipe, and fails due to undefined symbols: Could not import extension sphinx.builders.linkcheck (exception: /usr/lib64/python3.6/lib-dynload/_ssl.cpython-36m-x86_64-linux-gnu.so: symbol SSLv3_method, version OPENSSL_1_1_0 not defined in file libssl.so.1.1 with link time reference) Similar problem with librpmio.so.8, which is used during package generation on Fedora: rpmbuild: relocation error: /lib64/librpmio.so.8: symbol EVP_md2, version OPENSSL_1_1_0 not defined in file libcrypto.so.1.1 with link time reference It's harmless to enable these and we're effectively matching distro build settings for openssl, so should not be an issue.
That part is fixed. The remaining cerbero fedora issue is related to rpm debugsrc packages. Thanks !
reopening, still exists :( the issue is that the git https helper ends up picking up the openssl libraries we just built. They shouldn't they should be run with no LD_LIBRARY_PATH set.
Actually *any* host commands should not be using the cerbero LD_LIBRARY_PATH, it's ... wrong. I hate this world.
Created attachment 371675 [details] [review] source: Fix LD_LIBRARY_PATH when handling git commands For non-cross-compilation use-cases, we might end up building libraries in cerbero that should *not* be used by host commands. The case in point was the host "git" command picking up a mix of system libraries and of libraries that we built in cerbero. To avoid that, before running git commands switch to an environment which uses the "host" LD_LIBRARY_PATH environment
Review of attachment 371675 [details] [review]: Merge it already!