[PATCH v2] curl: allow build with c-ares library support.

[PATCH v2] curl: allow build with c-ares library support.

[Yevhen Kyriukha]

Also added c-ares library recipe.

In libcurl there is an issue with DNS lookups that cause crash on some platforms:
http://curl.haxx.se/mail/lib-2008-09/0197.html
To avoid this issue libcurl has to be built with c-ares name resolver.

Signed-off-by: Yevhen Kyriukha <kirgene@gmail.com>
---
 meta/recipes-support/c-ares/c-ares_1.10.0.bb | 24 ++++++++++++++++++++++++
 meta/recipes-support/curl/curl_7.33.0.bb     |  2 ++
 2 files changed, 26 insertions(+)
 create mode 100644 meta/recipes-support/c-ares/c-ares_1.10.0.bb

diff --git a/meta/recipes-support/c-ares/c-ares_1.10.0.bb b/meta/recipes-support/c-ares/c-ares_1.10.0.bb
new file mode 100644
index 0000000..23b3d0e
--- /dev/null
+++ b/meta/recipes-support/c-ares/c-ares_1.10.0.bb
@@ -0,0 +1,24 @@
+# Copyright (c) 2012-2013 LG Electronics, Inc.
+
+DESCRIPTION = "c-ares is a C library that resolves names asynchronously."
+HOMEPAGE = "http://daniel.haxx.se/projects/c-ares/"
+SECTION = "libs"
+LICENSE = "MIT"
+LIC_FILES_CHKSUM = "file://README;beginline=17;endline=18;md5=b320556568bc067d215a1e34c5b34a14"
+
+inherit autotools
+inherit pkgconfig
+
+SRC_URI = "http://c-ares.haxx.se/download/${BP}.tar.gz"
+SRC_URI[md5sum] = "1196067641411a75d3cbebe074fd36d8"
+SRC_URI[sha256sum] = "3d701674615d1158e56a59aaede7891f2dde3da0f46a6d3c684e0ae70f52d3db"
+
+EXTRA_OECONF = "--enable-shared"
+
+# install private headers to ares subdirectory
+do_install_append() {
+    install -d ${D}/${includedir}/ares
+    install -m 0644 ares*.h ${D}/${includedir}/ares/
+}
+
+FILES_${PN}-dev += "${includedir}/ares/*.h"
diff --git a/meta/recipes-support/curl/curl_7.33.0.bb b/meta/recipes-support/curl/curl_7.33.0.bb
index 8539fec..717c4f9 100644
--- a/meta/recipes-support/curl/curl_7.33.0.bb
+++ b/meta/recipes-support/curl/curl_7.33.0.bb
@@ -23,6 +23,8 @@ SRC_URI[sha256sum] = "0afde4cd949e2658eddc3cda675b19b165eea1af48ac5f3e1ec1607922
 
 inherit autotools pkgconfig binconfig
 
+PACKAGECONFIG[c-ares] = "--enable-ares,--disable-ares,c-ares"
+
 EXTRA_OECONF = "--with-zlib=${STAGING_LIBDIR}/../ \
                 --without-libssh2 \
                 --with-random=/dev/urandom \
-- 
1.8.1.2

Re: [PATCH v2] curl: allow build with c-ares library support.

[Saul Wold]

On 11/13/2013 06:51 AM, Yevhen Kyriukha wrote:
> Also added c-ares library recipe.
>
> In libcurl there is an issue with DNS lookups that cause crash on some platforms:
> http://curl.haxx.se/mail/lib-2008-09/0197.html
> To avoid this issue libcurl has to be built with c-ares name resolver.
>
This still does not fully explain why this is needed. Nor credits to 
origin of the c-ares recipe.

You also did not address Phil Blundell's comment about causing other 
issues, and possibibly using the existing libcurl internal threaded 
resolver.

Can you test with the internal resolver to see if it address your 
issues, before we add a new recipe.

> Signed-off-by: Yevhen Kyriukha <kirgene@gmail.com>
> ---
>   meta/recipes-support/c-ares/c-ares_1.10.0.bb | 24 ++++++++++++++++++++++++
>   meta/recipes-support/curl/curl_7.33.0.bb     |  2 ++
>   2 files changed, 26 insertions(+)
>   create mode 100644 meta/recipes-support/c-ares/c-ares_1.10.0.bb
>

This still needs to be split into 2 distict patches, one adding the 
c-ares recipe and a second one to use the PACKAGECONFIG.

Sau!

> diff --git a/meta/recipes-support/c-ares/c-ares_1.10.0.bb b/meta/recipes-support/c-ares/c-ares_1.10.0.bb
> new file mode 100644
> index 0000000..23b3d0e
> --- /dev/null
> +++ b/meta/recipes-support/c-ares/c-ares_1.10.0.bb
> @@ -0,0 +1,24 @@
> +# Copyright (c) 2012-2013 LG Electronics, Inc.
> +
> +DESCRIPTION = "c-ares is a C library that resolves names asynchronously."
> +HOMEPAGE = "http://daniel.haxx.se/projects/c-ares/"
> +SECTION = "libs"
> +LICENSE = "MIT"
> +LIC_FILES_CHKSUM = "file://README;beginline=17;endline=18;md5=b320556568bc067d215a1e34c5b34a14"
> +
> +inherit autotools
> +inherit pkgconfig
> +
> +SRC_URI = "http://c-ares.haxx.se/download/${BP}.tar.gz"
> +SRC_URI[md5sum] = "1196067641411a75d3cbebe074fd36d8"
> +SRC_URI[sha256sum] = "3d701674615d1158e56a59aaede7891f2dde3da0f46a6d3c684e0ae70f52d3db"
> +
> +EXTRA_OECONF = "--enable-shared"
> +
> +# install private headers to ares subdirectory
> +do_install_append() {
> +    install -d ${D}/${includedir}/ares
> +    install -m 0644 ares*.h ${D}/${includedir}/ares/
> +}
> +
> +FILES_${PN}-dev += "${includedir}/ares/*.h"
> diff --git a/meta/recipes-support/curl/curl_7.33.0.bb b/meta/recipes-support/curl/curl_7.33.0.bb
> index 8539fec..717c4f9 100644
> --- a/meta/recipes-support/curl/curl_7.33.0.bb
> +++ b/meta/recipes-support/curl/curl_7.33.0.bb
> @@ -23,6 +23,8 @@ SRC_URI[sha256sum] = "0afde4cd949e2658eddc3cda675b19b165eea1af48ac5f3e1ec1607922
>
>   inherit autotools pkgconfig binconfig
>
> +PACKAGECONFIG[c-ares] = "--enable-ares,--disable-ares,c-ares"
> +
>   EXTRA_OECONF = "--with-zlib=${STAGING_LIBDIR}/../ \
>                   --without-libssh2 \
>                   --with-random=/dev/urandom \
>

Re: [PATCH v2] curl: allow build with c-ares library support.

[Yevhen Kyriukha]

2013/11/13 Saul Wold <sgw@linux.intel.com>:
> On 11/13/2013 06:51 AM, Yevhen Kyriukha wrote:
>>
>> Also added c-ares library recipe.
>>
>> In libcurl there is an issue with DNS lookups that cause crash on some
>> platforms:
>> http://curl.haxx.se/mail/lib-2008-09/0197.html
>> To avoid this issue libcurl has to be built with c-ares name resolver.
>>
> This still does not fully explain why this is needed. Nor credits to origin
> of the c-ares recipe.
>

Do you meen to note layer name where I get this recipe from in commit?
The c-ares recipe was borrowed from meta-webos-ports.

> You also did not address Phil Blundell's comment about causing other issues,
> and possibibly using the existing libcurl internal threaded resolver.
>
> Can you test with the internal resolver to see if it address your issues,
> before we add a new recipe.
>

As far as I've tested curl crashes on i386 and Intel Cedartrail
platforms with internal threaded resolver.

Best regards,
Yevhen

>
>> Signed-off-by: Yevhen Kyriukha <kirgene@gmail.com>
>> ---
>>   meta/recipes-support/c-ares/c-ares_1.10.0.bb | 24
>> ++++++++++++++++++++++++
>>   meta/recipes-support/curl/curl_7.33.0.bb     |  2 ++
>>   2 files changed, 26 insertions(+)
>>   create mode 100644 meta/recipes-support/c-ares/c-ares_1.10.0.bb
>>
>
> This still needs to be split into 2 distict patches, one adding the c-ares
> recipe and a second one to use the PACKAGECONFIG.
>
> Sau!
>
>
>> diff --git a/meta/recipes-support/c-ares/c-ares_1.10.0.bb
>> b/meta/recipes-support/c-ares/c-ares_1.10.0.bb
>> new file mode 100644
>> index 0000000..23b3d0e
>> --- /dev/null
>> +++ b/meta/recipes-support/c-ares/c-ares_1.10.0.bb
>> @@ -0,0 +1,24 @@
>> +# Copyright (c) 2012-2013 LG Electronics, Inc.
>> +
>> +DESCRIPTION = "c-ares is a C library that resolves names asynchronously."
>> +HOMEPAGE = "http://daniel.haxx.se/projects/c-ares/"
>> +SECTION = "libs"
>> +LICENSE = "MIT"
>> +LIC_FILES_CHKSUM =
>> "file://README;beginline=17;endline=18;md5=b320556568bc067d215a1e34c5b34a14"
>> +
>> +inherit autotools
>> +inherit pkgconfig
>> +
>> +SRC_URI = "http://c-ares.haxx.se/download/${BP}.tar.gz"
>> +SRC_URI[md5sum] = "1196067641411a75d3cbebe074fd36d8"
>> +SRC_URI[sha256sum] =
>> "3d701674615d1158e56a59aaede7891f2dde3da0f46a6d3c684e0ae70f52d3db"
>> +
>> +EXTRA_OECONF = "--enable-shared"
>> +
>> +# install private headers to ares subdirectory
>> +do_install_append() {
>> +    install -d ${D}/${includedir}/ares
>> +    install -m 0644 ares*.h ${D}/${includedir}/ares/
>> +}
>> +
>> +FILES_${PN}-dev += "${includedir}/ares/*.h"
>> diff --git a/meta/recipes-support/curl/curl_7.33.0.bb
>> b/meta/recipes-support/curl/curl_7.33.0.bb
>> index 8539fec..717c4f9 100644
>> --- a/meta/recipes-support/curl/curl_7.33.0.bb
>> +++ b/meta/recipes-support/curl/curl_7.33.0.bb
>> @@ -23,6 +23,8 @@ SRC_URI[sha256sum] =
>> "0afde4cd949e2658eddc3cda675b19b165eea1af48ac5f3e1ec1607922
>>
>>   inherit autotools pkgconfig binconfig
>>
>> +PACKAGECONFIG[c-ares] = "--enable-ares,--disable-ares,c-ares"
>> +
>>   EXTRA_OECONF = "--with-zlib=${STAGING_LIBDIR}/../ \
>>                   --without-libssh2 \
>>                   --with-random=/dev/urandom \
>>
>


Best regards,
Yevhen

Re: [PATCH v2] curl: allow build with c-ares library support.

[Phil Blundell]

On Wed, 2013-11-13 at 19:25 +0200, Yevhen Kyriukha wrote:
> As far as I've tested curl crashes on i386 and Intel Cedartrail
> platforms with internal threaded resolver.

Crashes how?  The original problem you mentioned is specific to the
synchronous resolver.  The threaded resolver doesn't use SIGALRM at all.

p.

Re: [PATCH v2] curl: allow build with c-ares library support.

[Saul Wold]

On 11/13/2013 09:25 AM, Yevhen Kyriukha wrote:
> 2013/11/13 Saul Wold <sgw@linux.intel.com>:
>> On 11/13/2013 06:51 AM, Yevhen Kyriukha wrote:
>>>
>>> Also added c-ares library recipe.
>>>
>>> In libcurl there is an issue with DNS lookups that cause crash on some
>>> platforms:
>>> http://curl.haxx.se/mail/lib-2008-09/0197.html
>>> To avoid this issue libcurl has to be built with c-ares name resolver.
>>>
>> This still does not fully explain why this is needed. Nor credits to origin
>> of the c-ares recipe.
>>
>
> Do you meen to note layer name where I get this recipe from in commit?
> The c-ares recipe was borrowed from meta-webos-ports.
>
Yes, you need to say that as part of your patch, but I still want more 
details below about using the internal threaded resolver before we add a 
new recipe.

>> You also did not address Phil Blundell's comment about causing other issues,
>> and possibibly using the existing libcurl internal threaded resolver.
>>
>> Can you test with the internal resolver to see if it address your issues,
>> before we add a new recipe.
>>
>
> As far as I've tested curl crashes on i386 and Intel Cedartrail
> platforms with internal threaded resolver.
>
Did you explictly enable the threaded resolver with 
--enable-threaded-resolver?

Thanks
	Sau!


> Best regards,
> Yevhen
>
>>
>>> Signed-off-by: Yevhen Kyriukha <kirgene@gmail.com>
>>> ---
>>>    meta/recipes-support/c-ares/c-ares_1.10.0.bb | 24
>>> ++++++++++++++++++++++++
>>>    meta/recipes-support/curl/curl_7.33.0.bb     |  2 ++
>>>    2 files changed, 26 insertions(+)
>>>    create mode 100644 meta/recipes-support/c-ares/c-ares_1.10.0.bb
>>>
>>
>> This still needs to be split into 2 distict patches, one adding the c-ares
>> recipe and a second one to use the PACKAGECONFIG.
>>
>> Sau!
>>
>>
>>> diff --git a/meta/recipes-support/c-ares/c-ares_1.10.0.bb
>>> b/meta/recipes-support/c-ares/c-ares_1.10.0.bb
>>> new file mode 100644
>>> index 0000000..23b3d0e
>>> --- /dev/null
>>> +++ b/meta/recipes-support/c-ares/c-ares_1.10.0.bb
>>> @@ -0,0 +1,24 @@
>>> +# Copyright (c) 2012-2013 LG Electronics, Inc.
>>> +
>>> +DESCRIPTION = "c-ares is a C library that resolves names asynchronously."
>>> +HOMEPAGE = "http://daniel.haxx.se/projects/c-ares/"
>>> +SECTION = "libs"
>>> +LICENSE = "MIT"
>>> +LIC_FILES_CHKSUM =
>>> "file://README;beginline=17;endline=18;md5=b320556568bc067d215a1e34c5b34a14"
>>> +
>>> +inherit autotools
>>> +inherit pkgconfig
>>> +
>>> +SRC_URI = "http://c-ares.haxx.se/download/${BP}.tar.gz"
>>> +SRC_URI[md5sum] = "1196067641411a75d3cbebe074fd36d8"
>>> +SRC_URI[sha256sum] =
>>> "3d701674615d1158e56a59aaede7891f2dde3da0f46a6d3c684e0ae70f52d3db"
>>> +
>>> +EXTRA_OECONF = "--enable-shared"
>>> +
>>> +# install private headers to ares subdirectory
>>> +do_install_append() {
>>> +    install -d ${D}/${includedir}/ares
>>> +    install -m 0644 ares*.h ${D}/${includedir}/ares/
>>> +}
>>> +
>>> +FILES_${PN}-dev += "${includedir}/ares/*.h"
>>> diff --git a/meta/recipes-support/curl/curl_7.33.0.bb
>>> b/meta/recipes-support/curl/curl_7.33.0.bb
>>> index 8539fec..717c4f9 100644
>>> --- a/meta/recipes-support/curl/curl_7.33.0.bb
>>> +++ b/meta/recipes-support/curl/curl_7.33.0.bb
>>> @@ -23,6 +23,8 @@ SRC_URI[sha256sum] =
>>> "0afde4cd949e2658eddc3cda675b19b165eea1af48ac5f3e1ec1607922
>>>
>>>    inherit autotools pkgconfig binconfig
>>>
>>> +PACKAGECONFIG[c-ares] = "--enable-ares,--disable-ares,c-ares"
>>> +
>>>    EXTRA_OECONF = "--with-zlib=${STAGING_LIBDIR}/../ \
>>>                    --without-libssh2 \
>>>                    --with-random=/dev/urandom \
>>>
>>
>
>
> Best regards,
> Yevhen
>
>

Re: [PATCH v2] curl: allow build with c-ares library support.

[Phil Blundell]

On Wed, 2013-11-13 at 16:51 +0200, Yevhen Kyriukha wrote:
> +# Copyright (c) 2012-2013 LG Electronics, Inc.

Is this sort of thing wholesome?  The majority of recipes in oe-core
don't have any copyright statement and I'm not sure that adding one is
necessarily a good thing.

Out of curiosity I conducted a small survey of my current tree, which
contains 855 recipes of which 31 seem to have a copyright notice.  The
individuals and organisations asserting this copyright are:

OpenedHand Ltd (12 recipes, 2007-2008)
Intel Corporation (7 recipes, 2010-2012)
Advanced Micro Devices, Inc (4 recipes, 2004-2006)
Khem Raj (4 recipes, 2012-2013)
Wind River Ltd (1 recipe, 2012)
Matthias Hentges (1 recipe, 2007)
Red Hat, Inc (1 recipe, 2012)

OpenedHand Ltd was apparently dissolved two years ago so I guess its
copyright notices are just historical artifacts.

There's also one recipe (zisofs-tools-native) which contains the
assertion:

# Copyright (C) 1989, 1991 Free Software Foundation, Inc.

... which seems slightly bizarre since this would mean that the recipe
in question pre-dates the rest of OE by over a decade. 

p.

Re: [PATCH v2] curl: allow build with c-ares library support.

[Burton, Ross]

On 13 November 2013 18:00, Phil Blundell <pb@pbcl.net> wrote:
> OpenedHand Ltd was apparently dissolved two years ago so I guess its
> copyright notices are just historical artifacts.

FWIW, as of October 2008 anything that was (C) OpenedHand Ltd is (C) Intel Corp.

Ross

Re: [PATCH v2] curl: allow build with c-ares library support.

[Yevhen Kyriukha]

2013/11/13 Saul Wold <sgw@linux.intel.com>:
> On 11/13/2013 09:25 AM, Yevhen Kyriukha wrote:
>>
>> 2013/11/13 Saul Wold <sgw@linux.intel.com>:
>>>
>>> On 11/13/2013 06:51 AM, Yevhen Kyriukha wrote:
>>>>
>>>>
>>>> Also added c-ares library recipe.
>>>>
>>>> In libcurl there is an issue with DNS lookups that cause crash on some
>>>> platforms:
>>>> http://curl.haxx.se/mail/lib-2008-09/0197.html
>>>> To avoid this issue libcurl has to be built with c-ares name resolver.
>>>>
>>> This still does not fully explain why this is needed. Nor credits to
>>> origin
>>> of the c-ares recipe.
>>>
>>
>> Do you meen to note layer name where I get this recipe from in commit?
>> The c-ares recipe was borrowed from meta-webos-ports.
>>
> Yes, you need to say that as part of your patch, but I still want more
> details below about using the internal threaded resolver before we add a new
> recipe.
>
>
>>> You also did not address Phil Blundell's comment about causing other
>>> issues,
>>> and possibibly using the existing libcurl internal threaded resolver.
>>>
>>> Can you test with the internal resolver to see if it address your issues,
>>> before we add a new recipe.
>>>
>>
>> As far as I've tested curl crashes on i386 and Intel Cedartrail
>> platforms with internal threaded resolver.
>>
> Did you explictly enable the threaded resolver with
> --enable-threaded-resolver?
>
> Thanks
>         Sau!
>
>
>
>> Best regards,
>> Yevhen
>>
>>>
>>>> Signed-off-by: Yevhen Kyriukha <kirgene@gmail.com>
>>>> ---
>>>>    meta/recipes-support/c-ares/c-ares_1.10.0.bb | 24
>>>> ++++++++++++++++++++++++
>>>>    meta/recipes-support/curl/curl_7.33.0.bb     |  2 ++
>>>>    2 files changed, 26 insertions(+)
>>>>    create mode 100644 meta/recipes-support/c-ares/c-ares_1.10.0.bb
>>>>
>>>
>>> This still needs to be split into 2 distict patches, one adding the
>>> c-ares
>>> recipe and a second one to use the PACKAGECONFIG.
>>>
>>> Sau!
>>>
>>>
>>>> diff --git a/meta/recipes-support/c-ares/c-ares_1.10.0.bb
>>>> b/meta/recipes-support/c-ares/c-ares_1.10.0.bb
>>>> new file mode 100644
>>>> index 0000000..23b3d0e
>>>> --- /dev/null
>>>> +++ b/meta/recipes-support/c-ares/c-ares_1.10.0.bb
>>>> @@ -0,0 +1,24 @@
>>>> +# Copyright (c) 2012-2013 LG Electronics, Inc.
>>>> +
>>>> +DESCRIPTION = "c-ares is a C library that resolves names
>>>> asynchronously."
>>>> +HOMEPAGE = "http://daniel.haxx.se/projects/c-ares/"
>>>> +SECTION = "libs"
>>>> +LICENSE = "MIT"
>>>> +LIC_FILES_CHKSUM =
>>>>
>>>> "file://README;beginline=17;endline=18;md5=b320556568bc067d215a1e34c5b34a14"
>>>> +
>>>> +inherit autotools
>>>> +inherit pkgconfig
>>>> +
>>>> +SRC_URI = "http://c-ares.haxx.se/download/${BP}.tar.gz"
>>>> +SRC_URI[md5sum] = "1196067641411a75d3cbebe074fd36d8"
>>>> +SRC_URI[sha256sum] =
>>>> "3d701674615d1158e56a59aaede7891f2dde3da0f46a6d3c684e0ae70f52d3db"
>>>> +
>>>> +EXTRA_OECONF = "--enable-shared"
>>>> +
>>>> +# install private headers to ares subdirectory
>>>> +do_install_append() {
>>>> +    install -d ${D}/${includedir}/ares
>>>> +    install -m 0644 ares*.h ${D}/${includedir}/ares/
>>>> +}
>>>> +
>>>> +FILES_${PN}-dev += "${includedir}/ares/*.h"
>>>> diff --git a/meta/recipes-support/curl/curl_7.33.0.bb
>>>> b/meta/recipes-support/curl/curl_7.33.0.bb
>>>> index 8539fec..717c4f9 100644
>>>> --- a/meta/recipes-support/curl/curl_7.33.0.bb
>>>> +++ b/meta/recipes-support/curl/curl_7.33.0.bb
>>>> @@ -23,6 +23,8 @@ SRC_URI[sha256sum] =
>>>> "0afde4cd949e2658eddc3cda675b19b165eea1af48ac5f3e1ec1607922
>>>>
>>>>    inherit autotools pkgconfig binconfig
>>>>
>>>> +PACKAGECONFIG[c-ares] = "--enable-ares,--disable-ares,c-ares"
>>>> +
>>>>    EXTRA_OECONF = "--with-zlib=${STAGING_LIBDIR}/../ \
>>>>                    --without-libssh2 \
>>>>                    --with-random=/dev/urandom \
>>>>
>>>
>>
>>
>> Best regards,
>> Yevhen
>>
>>
>

Hmm... I thought that threaded resolver is used by default.
I had "longjmp causes uninitialized stack frame" error but enabling
threaded resolver explicitly fixed the problem.

Anyway I think that adding c-ares support in curl is good idea.
I'll prepare new version of patch (without mention of issue) if there
is no objections.

And in this case maybe it will be better to use threaded resolver by
default if c-ares is not specified.

How do you think?

Regards,
Yevhen