Building pycurl with CURL_SSL=nss gives the following run time error when used in python: Python 3.3.5 (default, Apr 12 2014, 17:42:55) [GCC 4.7.3] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import pycurl Traceback (most recent call last): File "<stdin>", line 1, in <module> ImportError: pycurl: libcurl link-time ssl backend (nss) is different from compile-time ssl backend (openssl) Reproducible: Always Steps to Reproduce: 1. set CURL_SSL="nss" in make.conf 2. run emerge --deep --newuse world (triggers build of pycurl and libcurl on my system 3. python -c 'import pycurl' Actual Results: Traceback (most recent call last): File "<string>", line 1, in <module> ImportError: pycurl: libcurl link-time ssl backend (nss) is different from compile-time ssl backend (openssl) As i did never specified the CURL_SSL before, i searched why it uses nss and found this note in /usr/portage/profiles/targets/desktop/gnome/package.use: # liboauth (required by evolution-data-server[gnome-online-accounts] and # gnome-documents in gnome-3.2) has +nss in IUSE, pulls in curl[-gnutls,nss] # In >=curl-7.25.0-r1, need CURL_SSL="-gnutls nss -openssl" net-misc/curl -curl_ssl_gnutls curl_ssl_nss -curl_ssl_openssl -gnutls nss dev-python/pycurl -curl_ssl_gnutls curl_ssl_nss -curl_ssl_openssl
Created attachment 377382 [details] emerge logfile for pycurl with nss The logfile from building pycurl with CURL_SSL=nss
Created attachment 377384 [details] emerge logfile for pycurl with openssl The logfile from building pycurl with CURL_SSL=openssl for reference
Created attachment 377386 [details] emerge --info for my system
Created attachment 377390 [details] fixed ebuild I am new to create ebuild files (so i do not know if this is "the right way to do it") but this updated ebuild fixes the problem. diff to current ebuild: --- pycurl-7.19.3.1.ebuild.orig 2014-05-21 22:52:44.199264012 +0200 +++ pycurl-7.19.3.1.ebuild 2014-05-21 23:41:00.136341563 +0200 @@ -40,7 +40,14 @@ python_compile() { python_is_python3 || local -x CFLAGS="${CFLAGS} -fno-strict-aliasing" - distutils-r1_python_compile + if use curl_ssl_gnutls ; then + conf_ssl="--with-gnutls" + elif use curl_ssl_nss ; then + conf_ssl="--with-nss" + elif use curl_ssl_openssl ; then + conf_ssl="--with-ssl" + fi + distutils-r1_python_compile ${conf_ssl} } src_test() {
(In reply to Hanspeter Spalinger from comment #4) > Created attachment 377390 [details] > fixed ebuild Here, building urlgrabber failed with the error "pycurl: libcurl link-time ssl backend (openssl) is different from compile-time ssl backend (gnutls)" - same error whenever "import pycurl" was done of course. The suggested ebuild change fixes it. Thanks!
(In reply to Bernd Feige from comment #5) Same here. Found this bug via build failure in urlgrabber, updated pycurl ebuild from Hanspeter Spalinger fixes this. Thanks!
blueness: Should we be using this new CURL_SSL use-expand here? Or is this some other issue?
Oh, I see we already are using it. Sorry for the confusion.
I am no able to reproduce the problem here. Can you please provide the output of curl-config --libs on a system where this failure happens?
% curl-config --libs -lcurl -lrtmp -lz -lssl -lcrypto -lssl3 -lsmime3 -lnss3 -lnssutil3 -lplds4 -lplc4 -lnspr4 -llber -lldap -lz Also: % equery u net-misc/curl dev-python/pycurl * Found these USE flags for net-misc/curl-7.37.0: U I - - adns - - curl_ssl_axtls - - curl_ssl_cyassl - - curl_ssl_gnutls + + curl_ssl_nss - - curl_ssl_openssl - - curl_ssl_polarssl - - curl_ssl_winssl - - idn + + ipv6 - - kerberos + + ldap - - metalink + + rtmp - - ssh + + ssl - - static-libs - - test + + threads * Found these USE flags for dev-python/pycurl-7.19.3.1-r1: U I - - curl_ssl_gnutls + + curl_ssl_nss - - curl_ssl_openssl - - examples + + python_targets_python2_7 - - python_targets_python3_2 + + python_targets_python3_3 - - python_targets_python3_4 + + ssl hth
Note: the -r1 tag on my dev-python/pycurl-7.19.3.1-r1 is from the updated ebuild from Mr. Spalinger.
Your copy of net-misc/curl is somehow linked with both openssl (-lcrypto -lssl3) and nss (-lnss3 -lnssutil3). This confuses the pycurl setup.py code.
(In reply to Mike Gilbert from comment #12) > Your copy of net-misc/curl is somehow linked with both openssl (-lcrypto > -lssl3) and nss (-lnss3 -lnssutil3). > > This confuses the pycurl setup.py code. (I think you wanted say openssl uses (-lcrypto -lssl) because lssl3 gets added even if using nss, but it works with lssl3) After a lot of use-flag testing I found the culprit is rtmpdump the rtmp use flag adds "-lrtmp -lz -lssl -lcrypto" even if ssl use flag is disabled in curl This comes from # pkg-config --libs librtmp Disabling the rtmp use flag makes pycurl work again without my hacky ebuild. curl-config --libs: -lcurl -lidn -lssh2 -lssh2 -lssl3 -lsmime3 -lnss3 -lnssutil3 -lplds4 -lplc4 -lnspr4 -L/usr/lib64 -lgssapi_krb5 -lkrb5 -lk5crypto -lcom_err -llber -lldap -lz * Found these USE flags for net-misc/curl-7.37.0: U I - - adns - - curl_ssl_axtls - - curl_ssl_cyassl - - curl_ssl_gnutls + + curl_ssl_nss - - curl_ssl_openssl - - curl_ssl_polarssl - - curl_ssl_winssl + + idn + + ipv6 + + kerberos + + ldap - - metalink - - rtmp + + ssh + + ssl - - static-libs - - test - - threads Now I think I go find out if I realy need use nss in curl (this is coming from the gnome profile, but I think this may be outdated).
(In reply to Hanspeter Spalinger from comment #13) > (In reply to Mike Gilbert from comment #12) > > Your copy of net-misc/curl is somehow linked with both openssl (-lcrypto > > -lssl3) and nss (-lnss3 -lnssutil3). > > > > This confuses the pycurl setup.py code. > (I think you wanted say openssl uses (-lcrypto -lssl) because lssl3 gets > added even if using nss, but it works with lssl3) > > > After a lot of use-flag testing I found the culprit is rtmpdump > the rtmp use flag adds "-lrtmp -lz -lssl -lcrypto" even if ssl use flag is > disabled in curl > This comes from # pkg-config --libs librtmp > > Disabling the rtmp use flag makes pycurl work again without my hacky ebuild. > curl-config --libs: > -lcurl -lidn -lssh2 -lssh2 -lssl3 -lsmime3 -lnss3 -lnssutil3 -lplds4 -lplc4 > -lnspr4 -L/usr/lib64 -lgssapi_krb5 -lkrb5 -lk5crypto -lcom_err -llber -lldap > -lz > > * Found these USE flags for net-misc/curl-7.37.0: > U I > - - adns > - - curl_ssl_axtls > - - curl_ssl_cyassl > - - curl_ssl_gnutls > + + curl_ssl_nss > - - curl_ssl_openssl > - - curl_ssl_polarssl > - - curl_ssl_winssl > + + idn > + + ipv6 > + + kerberos > + + ldap > - - metalink > - - rtmp > + + ssh > + + ssl > - - static-libs > - - test > - - threads > > Now I think I go find out if I realy need use nss in curl (this is coming > from the gnome profile, but I think this may be outdated). Can I get your exact use flags on curl: `emerge --info curl`
I have the problem with gnutls + nss3. Here's what I get 1) # emerge curl -vp These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild R ~] net-misc/curl-7.37.0 USE="ipv6 ldap rtmp ssl static-libs threads -adns -idn -kerberos -metalink -ssh {-test}" CURL_SSL="nss -axtls -cyassl -gnutls -openssl -polarssl -winssl" 0 kB Total: 1 package (1 reinstall), Size of downloads: 0 kB yellow ~ # ldd /usr/bin/curl linux-vdso.so.1 (0x00000348dd715000) libcurl.so.4 => /usr/lib64/libcurl.so.4 (0x00000348dd278000) libz.so.1 => /lib64/libz.so.1 (0x00000348dd060000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00000348dce41000) libc.so.6 => /lib64/libc.so.6 (0x00000348dca82000) librtmp.so.1 => /usr/lib64/librtmp.so.1 (0x00000348dc862000) libgmp.so.10 => /usr/lib64/libgmp.so.10 (0x00000348dc5e0000) libhogweed.so.2 => /usr/lib64/libhogweed.so.2 (0x00000348dc3ae000) libnettle.so.4 => /usr/lib64/libnettle.so.4 (0x00000348dc17a000) libssl3.so => /usr/lib64/libssl3.so (0x00000348dbf28000) libsmime3.so => /usr/lib64/libsmime3.so (0x00000348dbcf5000) libnss3.so => /usr/lib64/libnss3.so (0x00000348db999000) libnssutil3.so => /usr/lib64/libnssutil3.so (0x00000348db769000) libplds4.so => /usr/lib64/libplds4.so (0x00000348db564000) libplc4.so => /usr/lib64/libplc4.so (0x00000348db35e000) libnspr4.so => /usr/lib64/libnspr4.so (0x00000348db114000) libldap-2.4.so.2 => /usr/lib64/libldap-2.4.so.2 (0x00000348daec6000) liblber-2.4.so.2 => /usr/lib64/liblber-2.4.so.2 (0x00000348dacb4000) libresolv.so.2 => /lib64/libresolv.so.2 (0x00000348daa9c000) libgnutls.so.26 => /usr/lib64/libgnutls.so.26 (0x00000348da7d2000) libgcrypt.so.11 => /usr/lib64/libgcrypt.so.11 (0x00000348da547000) libgpg-error.so.0 => /usr/lib64/libgpg-error.so.0 (0x00000348da342000) /lib64/ld-linux-x86-64.so.2 (0x00000348dd4f3000) libdl.so.2 => /lib64/libdl.so.2 (0x00000348da13e000) librt.so.1 => /lib64/librt.so.1 (0x00000348d9f35000) libtasn1.so.3 => /usr/lib64/libtasn1.so.3 (0x00000348d9d23000) CURL_SSL=-gnutls and yet linkage against libgnutls.so.26. I have to recompile with both USE="-rtmp -ldap" to get # ldd /usr/bin/curl linux-vdso.so.1 (0x000003005a95f000) libcurl.so.4 => /usr/lib64/libcurl.so.4 (0x000003005a4c6000) libz.so.1 => /lib64/libz.so.1 (0x000003005a2ae000) libpthread.so.0 => /lib64/libpthread.so.0 (0x000003005a08f000) libc.so.6 => /lib64/libc.so.6 (0x0000030059cd0000) libssl3.so => /usr/lib64/libssl3.so (0x0000030059a7e000) libsmime3.so => /usr/lib64/libsmime3.so (0x000003005984b000) libnss3.so => /usr/lib64/libnss3.so (0x00000300594ef000) libnssutil3.so => /usr/lib64/libnssutil3.so (0x00000300592bf000) libplds4.so => /usr/lib64/libplds4.so (0x00000300590ba000) libplc4.so => /usr/lib64/libplc4.so (0x0000030058eb4000) libnspr4.so => /usr/lib64/libnspr4.so (0x0000030058c6a000) /lib64/ld-linux-x86-64.so.2 (0x000003005a73d000) libdl.so.2 => /lib64/libdl.so.2 (0x0000030058a66000) librt.so.1 => /lib64/librt.so.1 (0x000003005885d000) 2) I have # emerge -vp rtmpdump These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild R ] media-video/rtmpdump-2.4_p20131018 USE="gnutls ssl (-polarssl)" 140 kB This is the old style USE flag system with ssl by itself means openssl, ssl + gnutls or polarssl means gnutls or polarssl respectively and no ssl means no ssl. Here's a snippet from rtmpdump: DEPEND="ssl? ( gnutls? ( net-libs/gnutls ) polarssl? ( !gnutls? ( >=net-libs/polarssl-0.14.0 ) ) !gnutls? ( !polarssl? ( dev-libs/openssl ) ) ) sys-libs/zlib" RDEPEND="${DEPEND}" S="${WORKDIR}" pkg_setup() { if ! use ssl && ( use gnutls || use polarssl ) ; then ewarn "USE='gnutls polarssl' are ignored without USE='ssl'." ewarn "Please review the local USE flags for this package." fi } 3) The same story with openldap: RDEPEND=" ssl? ( !gnutls? ( dev-libs/openssl ) gnutls? ( net-libs/gnutls dev-libs/libgcrypt:0 ) ) 4) In my opinion, openldap and rtmpdump should switch over to the new CURL_SSL flags. In fact, I think we should even just rename that use expand to SSL and be uniform thorughout the tree. The idea that USE=ssl sometimes means "you get ssl from some provider" and sometimes means "you get ssl from openssl" is confusing. Markos, I hope it wasn't too presumptuous of me to switch the title, and pass the buck onto you. Also, I don't know what the ldap herd wants to do because ldap is more entrenched and may not be able to switch as easily.
(In reply to Anthony Basile from comment #14) > Can I get your exact use flags on curl: `emerge --info curl` net-misc/curl-7.37.0 was built with the following: USE="idn ipv6 kerberos ldap ssh ssl -adns -metalink -rtmp -static-libs -test -threads" CURL_SSL="nss -axtls -cyassl -gnutls -openssl -polarssl -winssl" pycurl is working from this example: #python -c 'import pycurl' openldap was build using openssl: net-nds/openldap-2.4.38-r1 was built with the following: USE="berkdb crypt icu ipv6 kerberos minimal sasl ssl syslog tcpd -cxx -debug -experimental -gnutls -iodbc -odbc -overlays -perl -samba (-selinux) -slp -smbkrb5passwd" And curl IS linking against libssl and libcrypto. # ldd /usr/bin/curl linux-vdso.so.1 (0x00007fff107d2000) libcurl.so.4 => /usr/lib64/libcurl.so.4 (0x00007f959218b000) libz.so.1 => /lib64/libz.so.1 (0x00007f9591f75000) libc.so.6 => /lib64/libc.so.6 (0x00007f9591bd3000) libidn.so.11 => /usr/lib64/libidn.so.11 (0x00007f959199f000) libssh2.so.1 => /usr/lib64/libssh2.so.1 (0x00007f9591776000) libssl3.so => /usr/lib64/libssl3.so (0x00007f959152c000) libsmime3.so => /usr/lib64/libsmime3.so (0x00007f95912ff000) libnss3.so => /usr/lib64/libnss3.so (0x00007f9590fc2000) libnssutil3.so => /usr/lib64/libnssutil3.so (0x00007f9590d96000) libplds4.so => /usr/lib64/libplds4.so (0x00007f9590b92000) libplc4.so => /usr/lib64/libplc4.so (0x00007f959098d000) libnspr4.so => /usr/lib64/libnspr4.so (0x00007f9590750000) libgssapi_krb5.so.2 => /usr/lib64/libgssapi_krb5.so.2 (0x00007f959050a000) libkrb5.so.3 => /usr/lib64/libkrb5.so.3 (0x00007f959023c000) libk5crypto.so.3 => /usr/lib64/libk5crypto.so.3 (0x00007f959000c000) libcom_err.so.2 => /lib64/libcom_err.so.2 (0x00007f958fe08000) libldap-2.4.so.2 => /usr/lib64/libldap-2.4.so.2 (0x00007f958fbbd000) liblber-2.4.so.2 => /usr/lib64/liblber-2.4.so.2 (0x00007f958f9ae000) libsasl2.so.3 => /usr/lib64/libsasl2.so.3 (0x00007f958f791000) libdl.so.2 => /lib64/libdl.so.2 (0x00007f958f58d000) libresolv.so.2 => /lib64/libresolv.so.2 (0x00007f958f376000) libssl.so.1.0.0 => /usr/lib64/libssl.so.1.0.0 (0x00007f958f109000) libcrypto.so.1.0.0 => /usr/lib64/libcrypto.so.1.0.0 (0x00007f958ed3b000) /lib64/ld-linux-x86-64.so.2 (0x00007f95923fa000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f958eb1e000) librt.so.1 => /lib64/librt.so.1 (0x00007f958e916000) libkrb5support.so.0 => /usr/lib64/libkrb5support.so.0 (0x00007f958e70a000) libkeyutils.so.1 => /lib64/libkeyutils.so.1 (0x00007f958e506000) The reason pycurl works with the python build is that libssl and libcrypto do NOT apear in curl-config and setup.py correctly detects to use nss: $ curl-config --libs -lcurl -lidn -lssh2 -lssh2 -lssl3 -lsmime3 -lnss3 -lnssutil3 -lplds4 -lplc4 -lnspr4 -L/usr/lib64 -lgssapi_krb5 -lkrb5 -lk5crypto -lcom_err -llber -lldap -lz
For pycurl, it is probably a good idea to override the setup.py code anyway. + 28 May 2014; Mike Gilbert <floppym@gentoo.org> pycurl-7.19.0-r3.ebuild, + pycurl-7.19.3.1.ebuild: + Override faulty curl ssl detection in setup.py, bug 510974 by Hanspeter + Spalinger.
(In reply to Mike Gilbert from comment #17) > For pycurl, it is probably a good idea to override the setup.py code anyway. > > + 28 May 2014; Mike Gilbert <floppym@gentoo.org> pycurl-7.19.0-r3.ebuild, > + pycurl-7.19.3.1.ebuild: > + Override faulty curl ssl detection in setup.py, bug 510974 by Hanspeter > + Spalinger. is anything more needed after this change in pycurl?
(In reply to Pacho Ramos from comment #18) > (In reply to Mike Gilbert from comment #17) > > For pycurl, it is probably a good idea to override the setup.py code anyway. > > > > + 28 May 2014; Mike Gilbert <floppym@gentoo.org> pycurl-7.19.0-r3.ebuild, > > + pycurl-7.19.3.1.ebuild: > > + Override faulty curl ssl detection in setup.py, bug 510974 by Hanspeter > > + Spalinger. > > is anything more needed after this change in pycurl? For me everything is working fine with the current dev-python/pycurl-7.43.0.2 so I guess this can be closed.
thanks for the feedback :)
