Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1785720

Summary: git not finding libcurl-httpd
Product: Red Hat Software Collections Reporter: Paul Lai (Intel) <plai>
Component: curlAssignee: Luboš Uhliarik <luhliari>
Status: CLOSED WORKSFORME QA Contact: BaseOS QE - Apps <qe-baseos-apps>
Severity: high Docs Contact:
Priority: unspecified    
Version: httpd24CC: ehabkost, jorton, kdudka, plai, redhat
Target Milestone: alpha   
Target Release: 3.4   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-04-16 10:47:20 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Paul Lai (Intel) 2019-12-20 18:48:48 UTC
Description of problem:

[plai@rhel73-plai-intel rhel8]$ git pull origin rhel-8.2.0
> /opt/rh/rh-git218/root/usr/libexec/git-core/git-remote-https: error while loading shared libraries: libcurl-httpd24.so.4: cannot open shared object file: No such file or directory


Version-Release number of selected component (if applicable):
RHEL 7.x (vm guest)

How reproducible:
100% (after 12/20 VM reboot)

Steps to Reproduce:
1. git pull origin rhel-8.2.0


Actual results:
/opt/rh/rh-git218/root/usr/libexec/git-core/git-remote-https: error while
+loading shared libraries: libcurl-httpd24.so.4: cannot open shared object file:
+No such file or directory

Expected results:
No errors, `git pull` should just function

Additional info:
 > [plai@rhel73-plai-intel rhel8]$ rpmquery -l httpd24-libcurl
> > /opt/rh/httpd24/root/usr/lib64/libcurl-httpd24.so.4
> > /opt/rh/httpd24/root/usr/lib64/libcurl-httpd24.so.4.5.0
> > /opt/rh/httpd24/root/usr/share/licenses/httpd24-libcurl-7.61.1
> > /opt/rh/httpd24/root/usr/share/licenses/httpd24-libcurl-7.61.1/COPYING


Work around:

[root@rhel73-plai-intel rhel8]# cd /lib64
[root@rhel73-plai-intel lib64]# ln -s /opt/rh/httpd24/root/usr/lib64/libcurl-httpd24.so.4

The httpd24-libcurl rpm needs to be fixed to place binaries in the "right" place.

Comment 2 Eduardo Habkost 2019-12-20 20:14:54 UTC
Do you have the exact version+release of git and libcurl RPMs?

Comment 3 Paul Lai (Intel) 2019-12-20 21:12:55 UTC
(In reply to Eduardo Habkost from comment #2)
> Do you have the exact version+release of git and libcurl RPMs?

[plai@rhel73-plai-intel rhel8]$ rpmquery -i git
git-1.8.3.1-20.el7.x86_64

[plai@rhel73-plai-intel rhel8]$ rpmquery -i httpd24-libcurl
httpd24-libcurl-7.61.1-1.el7.x86_64

Comment 4 Joe Orton 2020-02-27 15:22:42 UTC
I can't reproduce here.  Are you running git directly without enabling the collection?

[root@ci-vm-10-0-137-137 ~]# scl enable rh-git218 bash
[root@ci-vm-10-0-137-137 ~]# git clone https://github.com/apache/httpd
Cloning into 'httpd'...
remote: Enumerating objects: 40, done.
remote: Counting objects: 100% (40/40), done.
...

The collection appears to correctly set LD_LIBRARY_PATH so this should work.

[root@ci-vm-10-0-137-137 ~]# cat /opt/rh/rh-git218/enable 
export PATH=/opt/rh/rh-git218/root/usr/bin${PATH:+:${PATH}}
export MANPATH=/opt/rh/rh-git218/root/usr/share/man:${MANPATH}
export PERL5LIB=/opt/rh/rh-git218/root/usr/share/perl5/vendor_perl${PERL5LIB:+:${PERL5LIB}}
export LD_LIBRARY_PATH=/opt/rh/httpd24/root/usr/lib64${LD_LIBRARY_PATH:+:${LD_LIBRARY_PATH}}

[root@ci-vm-10-0-137-137 ~]# rpm -q rh-git218 rh-git218-git httpd24-libcurl
rh-git218-3.2-1.el7.x86_64
rh-git218-git-2.18.2-1.el7.x86_64
httpd24-libcurl-7.61.1-2.el7.x86_64

Comment 5 Richard 2020-04-16 10:25:42 UTC
I'm having the same issue. The problem is that loading libcurl-httpd24.so.4 needs LD_LIBRARY_PATH to be set. This is done by "scl enable rh-git218" and explains above but this environment variable get's cleared by sudo. I fixed this with:

echo /opt/rh/httpd24/root/usr/lib64 > /etc/ld.so.conf.d/rh-git218-fix.conf

Comment 6 Joe Orton 2020-04-16 10:47:20 UTC
To be clear, the supported mechanism for enabling and using an SCL is the environment provided by "scl enable <SCL>".

It is possible to partially reproduce that environment (e.g. comment 5) by hand, but please be aware you are using the packages outside of the environment in which they are validated and tested.  Manual hacks may e.g. break across updates to the SCL, are not supported, and we strongly recommend not relying on them in a production environment.

I'm going to close this since there doesn't seem to be a repro case based on using the SCL correctly.