xmlrpc-c of any version when compiled with "curl" flag enabled fails to comile. Reproducible: Always Steps to Reproduce: curl version: curl-7.18.1 Log of the failure: x86_64-pc-linux-gnu-gcc -c -I/var/tmp/portage/dev-libs/xmlrpc-c-1.06.03/work/xmlrpc-c-1.06.03/lib/curl_transport/../.. -I/var/tmp/portage/dev-libs/xmlrpc-c-1.06.03/work/xmlrpc-c-1.06.03/lib/curl_transport/../../include -I/var/tmp/portage/dev-libs/xmlrpc-c-1.06.03/work/xmlrpc-c-1.06.03/lib/curl_transport/../../lib/util/include -DNDEBUG -Wall -Wundef -Wimplicit -W -Winline -Wundef -Wmissing-declarations -Wstrict-prototypes -Wmissing-prototypes -fno-common -g -O3 xmlrpc_curl_transport.c -fPIC -DPIC -o .libs/xmlrpc_curl_transport.lo xmlrpc_curl_transport.c:1217:69: error: macro "curl_easy_setopt" requires 3 arguments, but only 2 given xmlrpc_curl_transport.c: In function 'setupCurlSession': xmlrpc_curl_transport.c:1217: warning: statement with no effect make[2]: *** [xmlrpc_curl_transport.lo] Ошибка 1 make[2]: Leaving directory `/var/tmp/portage/dev-libs/xmlrpc-c-1.06.03/work/xmlrpc-c-1.06.03/lib/curl_transport' make[1]: *** [curl_transport/all] Ошибка 2 make[1]: Leaving directory `/var/tmp/portage/dev-libs/xmlrpc-c-1.06.03/work/xmlrpc-c-1.06.03/lib' make: *** [lib/all] Ошибка 2 * * ERROR: dev-libs/xmlrpc-c-1.06.03 failed. * Call stack: * ebuild.sh, line 49: Called src_compile * environment, line 2123: Called die * The specific snippet of code: * emake || die "emake failed" * The die message: * emake failed * * If you need support, post the topmost build error, and the call stack if relevant. * A complete build log is located at '/var/tmp/portage/dev-libs/xmlrpc-c-1.06.03/temp/build.log'. * The ebuild environment file is located at '/var/tmp/portage/dev-libs/xmlrpc-c-1.06.03/temp/environment'.
The correction to this problem is quite easy. The problematic line is: curl_easy_setopt(curlSessionP, CURLOPT_SSLENGINE_DEFAULT); But the curl_easy_setopt() accepts three params and if I am not wrong it should looks like: curl_easy_setopt(curlSessionP, CURLOPT_SSLENGINE_DEFAULT, 1); Works fine witch this small change.
Created attachment 148879 [details, diff] correction of the call of "curl_easy_setopt" Here a patch to include the illusion's correction
Created attachment 148881 [details, diff] patch of the ebuild for use xmlrpc-c-1.06.09-curl-opt.patch it works and compiles on ~ppc
(In reply to comment #3) > Created an attachment (id=148881) [edit] > patch of the ebuild for use xmlrpc-c-1.06.09-curl-opt.patch > > it works and compiles on ~ppc > same for ~amd64
Yeah. The patch is fine. Tested on ~x86. Thanks guys.
*** Bug 217945 has been marked as a duplicate of this bug. ***
(In reply to comment #6) > *** Bug 217945 has been marked as a duplicate of this bug. *** > sorry for a duplicate bug, somehow I didn't see this one.
The patches work fine for me as well. Any idea about when this might make it to the tree?
*** Bug 218640 has been marked as a duplicate of this bug. ***
(In reply to comment #1) > The correction to this problem is quite easy. The problematic line is: > > curl_easy_setopt(curlSessionP, CURLOPT_SSLENGINE_DEFAULT); > > But the curl_easy_setopt() accepts three params and if I am not wrong it should > looks like: > > curl_easy_setopt(curlSessionP, CURLOPT_SSLENGINE_DEFAULT, 1); > > Works fine witch this small change. > Are you sure it should not be: curl_easy_setopt(curlSessionP, CURLOPT_SSLENGINE_DEFAULT, curlSetupP->sslEngineDefault); Thats more how the surrounding code looks like. Did you report upstream?
Acording to curl documentation 1 is a correct value in this case (Look at the note): -------- CURLOPT_SSLENGINE_DEFAULT Sets the actual crypto engine as the default for (asymmetric) crypto operations. If the crypto device cannot be set, CURLE_SSL_ENGINE_SETFAILED is returned. Note that even though this option doesn't need any parameter, in some configurations curl_easy_setopt might be defined as a macro taking exactly three arguments. Therefore, it's recommended to pass 1 as parameter to this option. -------- And I am affraid I has not enough time to report it upstream yet ;(
This problem shows up on x86 as well as AMD64. Noting applies to x86 as the bug is in the AMD64 group only. Is it possible we can put the existing patch up into the tree, even if its masked. Thanks
I've committed the fix (I have to do a similar one to mediatomb too, 1 is the correct value).