On 08/03/2016 05:33 PM, Thomas Eriksson wrote:> On 08/03/2016 05:23 PM, Alice Wonder wrote: >> On 08/03/2016 05:20 PM, Alice Wonder wrote: >>> On 08/03/2016 05:11 PM, Alice Wonder wrote: >>>> I'm having a major frustration with curl. >>>> >>>> When building curl, if libssl.so.10 is present the curl binary WILL link >>>> against it. >>> >>> *snip* >>> >>> Go ahead and ldd on the CentOS curl binary and library - you will see >>> openssl linked even though the spec file has --disable-ssl and >>> --enable-nss >>> >>> It's clearly broken. >>> >> >> And building the CentOS curl package doesn't even BuildRequires the >> openssl-devel package. >> >> It's linking against a library it doesn't have the headers for. >> >> That's broken. > > I haven't looked at how curl is built, butit is likely that the build > links against some other package that is, in turn, built against > OpenSSL. > > You would not need the openssl-devel package to do that, only the > runtime libraries. > > It looks like that package could be libssh2...It's not libssh2 because I built libssh2 against LibreSSL and tested it with ldd and it doesn't use OpenSSL nor pull it in. And in trying to create a curl that doesn't link against anything TLS I put --disable-libssh2 into the configure. The curl library respects that configure switch when building, the curl binary does not - it links against it anyway (mock pulls it in for other things, pulling in the version I built against OpenSSL) I also built custom OpenSSH against LibreSSL (which required ripping out all the fips stuff) for the mock build too - it also isn't pulling in OpenSSL libs. Something in the curl build will always link the binary against OpenSSL if the openssl-lib package is present, and will always link the library against OpenSSL if any TLS option is enabled in the configure. This happens even openssl-devel is not installed in the mock build environment.
On 08/03/2016 05:45 PM, Alice Wonder wrote:> On 08/03/2016 05:33 PM, Thomas Eriksson wrote: >> On 08/03/2016 05:23 PM, Alice Wonder wrote: >>> On 08/03/2016 05:20 PM, Alice Wonder wrote: >>>> On 08/03/2016 05:11 PM, Alice Wonder wrote: >>>>> I'm having a major frustration with curl. >>>>> >>>>> When building curl, if libssl.so.10 is present the curl binary WILL >>>>> link >>>>> against it. >>>> >>>> *snip* >>>> >>>> Go ahead and ldd on the CentOS curl binary and library - you will see >>>> openssl linked even though the spec file has --disable-ssl and >>>> --enable-nss >>>> >>>> It's clearly broken. >>>> >>> >>> And building the CentOS curl package doesn't even BuildRequires the >>> openssl-devel package. >>> >>> It's linking against a library it doesn't have the headers for. >>> >>> That's broken. >> >> I haven't looked at how curl is built, butit is likely that the build >> links against some other package that is, in turn, built against >> OpenSSL. >> >> You would not need the openssl-devel package to do that, only the >> runtime libraries. >> >> It looks like that package could be libssh2... > > > It's not libssh2 because I built libssh2 against LibreSSL and tested it > with ldd and it doesn't use OpenSSL nor pull it in.*snip* It might be getting -lcrypto from libssh2 but then it should link against LibreSSL because that's what the libssh2 for the build environment is linked against. I suspect it might do the right thing and link against libressl if the openssl lib wasn't present. But despite the mock excludes, it gets pulled in by something. The excludes are in both base and updates. And work if trying to build a package that directly wants openssl or has a dependency that directly wants openssl. It seems the excludes fail when it is a dependency of a dependency.
On 08/03/2016 05:54 PM, Alice Wonder wrote:> On 08/03/2016 05:45 PM, Alice Wonder wrote: >> On 08/03/2016 05:33 PM, Thomas Eriksson wrote: >>> On 08/03/2016 05:23 PM, Alice Wonder wrote: >>>> On 08/03/2016 05:20 PM, Alice Wonder wrote: >>>>> On 08/03/2016 05:11 PM, Alice Wonder wrote: >>>>>> I'm having a major frustration with curl. >>>>>> >>>>>> When building curl, if libssl.so.10 is present the curl binary WILL >>>>>> link >>>>>> against it. >>>>> >>>>> *snip* >>>>> >>>>> Go ahead and ldd on the CentOS curl binary and library - you will see >>>>> openssl linked even though the spec file has --disable-ssl and >>>>> --enable-nss >>>>> >>>>> It's clearly broken. >>>>> >>>> >>>> And building the CentOS curl package doesn't even BuildRequires the >>>> openssl-devel package. >>>> >>>> It's linking against a library it doesn't have the headers for. >>>> >>>> That's broken. >>> >>> I haven't looked at how curl is built, butit is likely that the build >>> links against some other package that is, in turn, built against >>> OpenSSL. >>> >>> You would not need the openssl-devel package to do that, only the >>> runtime libraries. >>> >>> It looks like that package could be libssh2... >> >> >> It's not libssh2 because I built libssh2 against LibreSSL and tested it >> with ldd and it doesn't use OpenSSL nor pull it in. > > *snip* >*snip* Take the CentOS curl src.rpm package and add exit 1 to the beginning of %check so that it exits quickly w/o removing the BUILDROOT in mock. Start changing the configure switches disabling stuff and look at the library and the curl binary with ldd. You'll see the configure switches reduce what the library links against but not what the binary links against. It's configure is clearly broken. I tried disabling all the RHEL patches but the behavior is the same, it's not caused by a patch.
Once upon a time, Alice Wonder <alice at domblogger.net> said:> Something in the curl build will always link the binary against > OpenSSL if the openssl-lib package is present, and will always link > the library against OpenSSL if any TLS option is enabled in the > configure.No, it doesn't. You can see this by looking at the RPM dependencies; at least on CentOS 7 and Fedora 23, they don't depend on libssl.so at all. If either curl or libcurl.so were linked against libssl.so, the RPM would require it. I just tried building the CentOS 7 RPM of curl, changing the SPEC to remove the libssh2 settings, and I got a curl and libcurl that do not in any way depend on libssl. It is most definitely libssh2.so that requires libssl.so. If you want help, you need to stop repeating your claims and show some actual commands run, output, versions, etc. -- Chris Adams <linux at cmadams.net>
On 08/03/2016 06:13 PM, Chris Adams wrote:> Once upon a time, Alice Wonder <alice at domblogger.net> said: >> Something in the curl build will always link the binary against >> OpenSSL if the openssl-lib package is present, and will always link >> the library against OpenSSL if any TLS option is enabled in the >> configure. > > No, it doesn't. You can see this by looking at the RPM dependencies; at > least on CentOS 7 and Fedora 23, they don't depend on libssl.so at all. > If either curl or libcurl.so were linked against libssl.so, the RPM > would require it. > > I just tried building the CentOS 7 RPM of curl, changing the SPEC to > remove the libssh2 settings, and I got a curl and libcurl that do not in > any way depend on libssl. It is most definitely libssh2.so that > requires libssl.so. > > If you want help, you need to stop repeating your claims and show some > actual commands run, output, versions, etc. >[alice at pern ~]$ ldd /usr/bin/curl |grep crypto libk5crypto.so.3 => /lib64/libk5crypto.so.3 (0x00007f4524390000) libcrypto.so.10 => /lib64/libcrypto.so.10 (0x00007f45234ca000) [alice at pern ~]$ rpm -qf /lib64/libcrypto.so.10 openssl-libs-1.0.1e-51.el7_2.5.x86_64 [alice at pern ~]$ That's with stock CentOS packages