Re: mbed TLS and curl-config and NTLM

[Dan Fandrich]

On Tue, Apr 18, 2017 at 08:53:33PM +0300, Isaac Boukris via curl-library wrote:
> On Tue, Apr 18, 2017 at 2:06 AM, Dan Fandrich  wrote:
> > Tests 1013 and 1014 for my mbed TLS autobuilds are failing, due to invalid
> > output of curl-config --features and --protocols. The problem is that the
> > configure check that determines if SMB and NTLM support is available is
> > incomplete compared to the compile-time check. These are only available if 
> > mbed
> > TLS enables MD4 support which it doesn't by default as its comment explains:
> > "Uncomment to enable support for (rare) MD4-signed X.509 certs". The 
> > configure
> > check, however, only looks to see that mbed TLS is enabled at all.
> 
> I noticed we have lib/md4.c file which seem to provide an alternative
> implementation, maybe we could plug it in.

Excellent idea! That's just what I did.

>>> Dan
---
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette:   https://curl.haxx.se/mail/etiquette.html

Re: Keeping your clone in sync (was Re: minor issue with build)

[Daniel Stenberg]

On Fri, 21 Apr 2017, Michael Felt wrote:


I tried "make dist" - this 'stopped' at:
/bin/sh: roffit:  not found.


Oops, that's a mistake. I believe I just fixed and pushed a fix for this after 
this email. Normal builds or make dist should not need roffit (anymore).


BTW, if you want a tarball made the exact same way we do releases, make them 
with:


 $ ./maketgz 7.100.0-test

(where 7.100.0-test is the version name you pick for your tarball build)

--

 / daniel.haxx.se
---
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette:   https://curl.haxx.se/mail/etiquette.html

Re: Keeping your clone in sync (was Re: minor issue with build)

[Michael Felt]

On 21/04/2017 15:18, Daniel Stenberg wrote:

On Fri, 21 Apr 2017, Michael Felt wrote:

p.s. - Once upon a time I cloned curl (at least I think I did) - what 
is the correct way to update that, ideally via the command line 
(question may also be ignored as it is a git thing, not curl).


You can find many guides for this on the web, and the github version 
is here: https://help.github.com/articles/syncing-a-fork/


I'll however offer you a simplified version, especially if you don't 
have any local changes of your own in the cloned master branch (which 
I think is a good habit anyway, do your changes in new branches instead):


 $ cd root/of/clone/directory
 $ git pull --rebase

(in my case I have an alias for pull --rebase called "up" so I just 
run "git up" to get my local master in sync with the remote master)


It actually even works *with* local changes but will then rebase them 
for you, which you might want to be a bit careful with.


Thanks - I have heard of rebase. And I had not (yet) made a fork, so I 
could use the web interface to let it make a fork for me.


What follows is: about 'after that'

++

Forked curl

cloned to curl-master

cp -rp curl-master curl-1432

cd curl-1432

./buildconf

mkdir ../oot
cd ../oot
../curl-1432/configure
...
configure: Configured to build curl/libcurl:

  curl version: 7.54.1-DEV
  Host setup:   powerpc-ibm-aix6.1.9.0
  Install prefix:   /usr/local
  Compiler: cc -qlanglvl=extc89
  SSL support:  enabled (OpenSSL)
  SSH support:  no  (--with-libssh2)
  zlib support: enabled
  GSS-API support:  no  (--with-gssapi)
  TLS-SRP support:  enabled
  resolver: default (--enable-ares / --enable-threaded-resolver)
  IPv6 support: enabled
  Unix sockets support: enabled
  IDN support:  no  (--with-{libidn2,winidn})
  Build libcurl:Shared=yes, Static=no
  Built-in manual:  enabled
  --libcurl option: enabled (--disable-libcurl-option)
  Verbose errors:   enabled (--disable-verbose)
  SSPI support: no  (--enable-sspi)
  ca cert bundle:   no
  ca cert path: no
  ca fallback:  no
  LDAP support: no  (--enable-ldap / --with-ldap-lib / 
--with-lber-lib)

  LDAPS support:no  (--enable-ldaps)
  RTSP support: enabled
  RTMP support: no  (--with-librtmp)
  metalink support: no  (--with-libmetalink)
  PSL support:  no  (libpsl not found)
  HTTP2 support:disabled (--with-nghttp2)
  Protocols:DICT FILE FTP FTPS GOPHER HTTP HTTPS IMAP IMAPS 
POP3 POP3S RTSP SMB SMBS SMTP SMTPS TELNET TFTP


mich...@x071.home.local:[/data/prj/aixtools/github/oot]find .. -name curl.1
mich...@x071.home.local:[/data/prj/aixtools/github/oot]

reminder: curl-master - is the fork, curl-1432 is a copy of curl-master, 
oot == out of tree


mich...@x071.home.local:[/data/prj/aixtools/github/oot]ls ..
curl-1432  curl-master  oot

I tried "make dist" - this 'stopped' at:

make[2]: Entering directory `/data/prj/aixtools/github/oot/tests'
roffit ../../curl-1432/tests/testcurl.1 >testcurl.html
/bin/sh: roffit:  not found.
make[2]: *** [testcurl.html] Error 127
make[2]: Leaving directory `/data/prj/aixtools/github/oot/tests'
make[1]: *** [distdir] Error 1
make[1]: Leaving directory `/data/prj/aixtools/github/oot'
make: *** [dist] Error 2
mich...@x071.home.local:[/data/prj/aixtools/github/oot]

However, I now have curl.1

mich...@x071.home.local:[/data/prj/aixtools/github/oot]find .. -name curl.1
../oot/curl--/docs/curl.1
../oot/docs/curl.1

remove all, and try again cleanly in oot

mich...@x071.home.local:[/data/prj/aixtools/github/oot]rm -rf *

and run configure again...

mich...@x071.home.local:[/data/prj/aixtools/github/oot]../curl-1432/configure

same as above

make ...

completes normally.

And curl.1 is in the build aka oot directory-tree.

mich...@x071.home.local:[/data/prj/aixtools/github/oot]find .. -name curl.1
../oot/docs/curl.1

Just to be sure:

I tried running "make dist" again, and again it stops at 'roffit not found'

make[2]: Leaving directory `/data/prj/aixtools/github/oot/include'
 (cd tests && make  top_distdir=../curl-- distdir=../curl--/tests \
 am__remove_distdir=: am__skip_length_check=: am__skip_mode_fix=: 
distdir)

make[2]: Entering directory `/data/prj/aixtools/github/oot/tests'
roffit ../../curl-1432/tests/testcurl.1 >testcurl.html
/bin/sh: roffit:  not found.
make[2]: *** [testcurl.html] Error 127
make[2]: Leaving directory `/data/prj/aixtools/github/oot/tests'
make[1]: *** [distdir] Error 1
make[1]: Leaving directory `/data/prj/aixtools/github/oot'
make: *** [dist] Error 2
mich...@x071.home.local:[/data/prj/aixtools/github/oot]

mich...@x071.home.local:[/data/prj/aixtools/github/oot]find .. -name curl.1
../oot/curl--/docs/curl.1
../oot/docs/curl.1


Hope this helps!

---
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette:   https://curl.haxx.se/mail/etiquette.html

Re: Closing idle issues and pull-requests

[Daniel Stenberg]

On Fri, 21 Apr 2017, Michael Felt wrote:

As far as 90/14 days - what is your bigger concern? That something gets lost 
(removed) prematurely, or that it hangs around "too" long, before someone 
gets back to it.


My biggest concern is that some people will find it rude that their issue gets 
closed, which is why I want to make sure the issue is truly stale before 
taking that step. But at the same time I want to filter out the "unimportant" 
ones (as stale issues signal to me that they're not the important ones).


But for clarity: we made it 180/14 days in the config that is now active. 
Exactly ten issues have been marked stale because of this so far.


If this is only for "stale" pull-requests - may be fine, as the original 
author (pull-requestor) should still have their files. However, I know 
myself - I have days when I can look at git-related projects and/or 
respond/write to a mailing lists and then months where work prevents me from 
continued involvement.


It is for both issues and pull-requests. But no information is deleted or 
removed with a close so there's really no data-loss risk because of this. All 
of them can be re-opened just as easily as it was closed and it is also easy 
to create new issues.


Lastly - assuming the bot sends mail to "all" who have commented on a 
pull-request, 14 days may be a bit short. Just my luck - I go on vacation 
for 21 days and the bot sends mail I do not see for 19 days... imho: 14 days 
is cutting it tight.


Sure, I realize that, but first you need to leave it untouched for 180 days so 
why does 14, 21 or 28 days matter much after that long time? If the issue is 
important (to anyone) it really should not go stale that long. I don't think 
that final 14 days period will risk too many issues getting prematurely 
closed. And for the occasional ones that still do, we can just re-open them 
and add the new info.


--

 / daniel.haxx.se
---
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette:   https://curl.haxx.se/mail/etiquette.html

Re: Closing idle issues and pull-requests

[Michael Felt]

As far as 90/14 days - what is your bigger concern? That something gets 
lost (removed) prematurely, or that it hangs around "too" long, before 
someone gets back to it.


If this is only for "stale" pull-requests - may be fine, as the original 
author (pull-requestor) should still have their files. However, I know 
myself - I have days when I can look at git-related projects and/or 
respond/write to a mailing lists and then months where work prevents me 
from continued involvement.


Lastly - assuming the bot sends mail to "all" who have commented on a 
pull-request, 14 days may be a bit short. Just my luck - I go on 
vacation for 21 days and the bot sends mail I do not see for 19 days... 
imho: 14 days is cutting it tight.



On 4/7/2017 11:54 AM, Daniel Stenberg wrote:

Hi,

We regularly close bug reports and provided pull requests that don't 
go anywhere and are for all practical purposes abandoned[1]. This has 
been done pure manually. Bugs or work that get focus back can always 
be reopened or a new issue can be filed. It helps us filter out the 
"dead ones".


To streamline this policy and to remove the human factor from the 
equation a bit, I want to switch on a bot that will do this 
automatically[2] and I'm now looking for input and thoughts.


The idea is that the bot marks all "stale" issues that haven't had any 
activity for 90 days. If no further activity is noted in the 14 days 
following that, the issue gets closed.


The 90 and 14 numbers are configurable variables that I consider 
suitable but we can always tweak them. Now or in the future.


[1] = https://curl.haxx.se/docs/bugs.html#Closing_off_stalled_bugs
[2] = https://github.com/curl/curl/pull/1398



---
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette:   https://curl.haxx.se/mail/etiquette.html

Keeping your clone in sync (was Re: minor issue with build)

[Daniel Stenberg]

On Fri, 21 Apr 2017, Michael Felt wrote:

p.s. - Once upon a time I cloned curl (at least I think I did) - what is the 
correct way to update that, ideally via the command line (question may also 
be ignored as it is a git thing, not curl).


You can find many guides for this on the web, and the github version is here: 
https://help.github.com/articles/syncing-a-fork/


I'll however offer you a simplified version, especially if you don't have any 
local changes of your own in the cloned master branch (which I think is a good 
habit anyway, do your changes in new branches instead):


 $ cd root/of/clone/directory
 $ git pull --rebase

(in my case I have an alias for pull --rebase called "up" so I just run "git 
up" to get my local master in sync with the remote master)


It actually even works *with* local changes but will then rebase them for you, 
which you might want to be a bit careful with.


--

 / daniel.haxx.se
---
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette:   https://curl.haxx.se/mail/etiquette.html

Re: minor issue with build

[Michael Felt]

On 21/04/2017 14:24, Daniel Stenberg wrote:

On Fri, 21 Apr 2017, Michael Felt wrote:

The generated Makefile in ./src is not working on AIX (tried both AIX 
5.3 and AIX 6.1).


I would think it should work, but sadly - it does not seem to.

Here is the "diff -u" that fixes it for me.


Exactly that fix was attempted already as the discussion in 
https://github.com/curl/curl/issues/1432 tells (see commit 
5b4cbcf11d5), but it was reverted again in commit 7c145bb2a0a6c176 
since it doesn't work for out-of-tree builds.


Repeating - and I am doing out-of-tree builds - it seems that 
../docs/curl.1 is not found.


Target "all" is up to date.
Making all in src
echo '#include "tool_setup.h"' > tool_hugehelp.c
echo '#ifndef HAVE_LIBZ' >> tool_hugehelp.c
env LC_ALL=C /usr/bin/nroff -man  ../docs/curl.1 | 
/usr/bin/perl ../../src/curl-7.54.0/src/mkhelp.pl 
../../src/curl-7.54.0/docs/MANUAL >> tool_hugehelp.c

/usr/bin/nroff: can't open file ../docs/curl.1
echo '#else' >> tool_hugehelp.c
env LC_ALL=C /usr/bin/nroff -man  ../docs/curl.1 | 
/usr/bin/perl ../../src/curl-7.54.0/src/mkhelp.pl -c 
../../src/curl-7.54.0/docs/MANUAL >> tool_hugehelp.c

/usr/bin/nroff: can't open file ../docs/curl.1
Warning: compression requested but Gzip is not available
echo '#endif /* HAVE_LIBZ */' >> tool_hugehelp.c
make  all-am

This is "out-of-tree"
root@x064:[/data/prj/aixtools/curl-7.54.0]find . -name curl.1
root@x064:[/data/prj/aixtools/curl-7.54.0]

It is in the src area:

root@x064:[/data/prj/aixtools/curl-7.54.0]find ../src/curl-7.54.0 -name 
curl.1

../src/curl-7.54.0/docs/curl.1

Is this what the github discussion discusses?

p.s. - Once upon a time I cloned curl (at least I think I did) - what is 
the correct way to update that, ideally via the command line (question 
may also be ignored as it is a git thing, not curl).




---
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette:   https://curl.haxx.se/mail/etiquette.html

Re: minor issue with build

[Daniel Stenberg]

On Fri, 21 Apr 2017, Michael Felt wrote:

The generated Makefile in ./src is not working on AIX (tried both AIX 5.3 
and AIX 6.1).


I would think it should work, but sadly - it does not seem to.

Here is the "diff -u" that fixes it for me.


Exactly that fix was attempted already as the discussion in 
https://github.com/curl/curl/issues/1432 tells (see commit 5b4cbcf11d5), but 
it was reverted again in commit 7c145bb2a0a6c176 since it doesn't work for 
out-of-tree builds.


--

 / daniel.haxx.se
---
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette:   https://curl.haxx.se/mail/etiquette.html

minor issue with build

[Michael Felt]

The generated Makefile in ./src is not working on AIX (tried both AIX 
5.3 and AIX 6.1).


I would think it should work, but sadly - it does not seem to.

Here is the "diff -u" that fixes it for me.

--- Makefile-7.54   2017-04-21 12:12:03 +
+++ Makefile2017-04-21 12:14:57 +
@@ -2225,9 +2225,9 @@
 $(HUGE): $(MANPAGE) $(README) $(MKHELP)
echo '#include "tool_setup.h"' > $(HUGE)
echo '#ifndef HAVE_LIBZ' >> $(HUGE)
-   $(NROFF) $< | $(PERL) $(MKHELP) $(README) >> $(HUGE)
+   $(NROFF) $(MANPAGE) | $(PERL) $(MKHELP) $(README) >> $(HUGE)
echo '#else' >> $(HUGE)
-   $(NROFF) $< | $(PERL) $(MKHELP) -c $(README) >> $(HUGE)
+   $(NROFF) $(MANPAGE) | $(PERL) $(MKHELP) -c $(README) >> $(HUGE)
echo '#endif /* HAVE_LIBZ */' >> $(HUGE)
 # This generates the tool_hugehelp.c file uncompressed only
 #$(HUGE): $(MANPAGE) $(README) mkhelp.pl

---
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette:   https://curl.haxx.se/mail/etiquette.html

RE: Static libcurl size under Windows

[Rod Widdowson]

> Does anyone know why we're rolling all dependencies into static libcurl lib?

I looked and timed out.  I don't speak nmake too good but thus far it looks 
like an artefact of the way the dll is built "Put in appropriate references for 
everything".  Also I cannot get over this suspicion that the build is using the 
linker to create the archive ("you are in a maze of nested symbol indirection, 
all alike").

I'll look a bit more this weekend but thusfar I'm coming up dry I'm hoping 
someone with stronger nmake-fu than I will dive it.

/Rod


---
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette:   https://curl.haxx.se/mail/etiquette.html

a curl bug bounty program

[Daniel Stenberg]

Hi friends,

The other day I blogged[1] about there being a bug bounty program coordinated 
by Hacker One for which you can apply for if your detected curl security 
problems are serious enough. A few persons who reported curl bugs have already 
received payments. The highest paid one so far that I saw got 3,000 USD.


I think this is super awesome as I hope it can provide some extra energy to 
people to go in a little extra when trying to find problems in our products. 
Getting security problems reported (and fixed) is a good thing.


I'm now in communication with the good folks at Hacker One to see what we can 
do to cooperate to make it an ever better and perhaps more focused bounty 
program for curl issues. I'll probably get back with details on that if/when 
we accomplish something.


[1] = https://daniel.haxx.se/blog/2017/04/19/curl-bug-bounty/

--

 / daniel.haxx.se
---
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette:   https://curl.haxx.se/mail/etiquette.html

Re: possible patch release?

[Daniel Stenberg]

On Fri, 21 Apr 2017, Michael Felt wrote:

Make dies (no input file? because of /bin/sh rather than /bin/bash syntax 
perhaps?) with:


A work-around until we have this fixed is to use GNU make.

--

 / daniel.haxx.se
---
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette:   https://curl.haxx.se/mail/etiquette.html

Re: possible patch release?

[Ray Satiro via curl-library]

On 4/21/2017 2:51 AM, Michael Felt wrote:
> On 22/02/2017 19:21, Michael Felt wrote:
>> On 22/02/2017 14:37, Jan Ehrhardt wrote:
>>> Daniel Stenberg in gmane.comp.web.curl.library (Wed, 22 Feb 2017
>>> 08:16:42 +0100 (CET)):
 Due to issue #1276 [1] that was reported within an hour of the
 7.53.0 release,
 we're contemplating a follow-up patch release. All opinions and
 arguments for
 or against are welcome.
>>> +1, as I said in the issue.
>>
>> Well, I am about to test build for AIX - but if I understand correctly 
>
> I never got around to finishing 7.53, but 7.54 has a build issue (with
> the docs).
>
> Make dies (no input file? because of /bin/sh rather than /bin/bash
> syntax perhaps?) with:
>
> Making all in src
> echo '#include "tool_setup.h"' > tool_hugehelp.c
> echo '#ifndef HAVE_LIBZ' >> tool_hugehelp.c
> env LC_ALL=C /usr/bin/nroff -man   | /usr/bin/perl
> ../../src/curl-7.54.0/src/mkhelp.pl ../../src/curl-7.54.0/docs/MANUAL
> >> tool_hugehelp.c
>
> Regards,
>
> Michael
>
> p.s. - the summarized version (second call to make)
>
> root@x064:[/data/prj/aixtools/curl-7.54.0]make
> Making all in lib
> make  all-am
> Target "all-am" is up to date.
> Making all in docs
> Making all in libcurl
> Making all in opts
> Target "all" is up to date.
> Target "all-am" is up to date.
> Target "all" is up to date.
> Making all in cmdline-opts
> Target "all" is up to date.
> Target "all-am" is up to date.
> Target "all" is up to date.
> Making all in src
> echo '#include "tool_setup.h"' > tool_hugehelp.c
> echo '#ifndef HAVE_LIBZ' >> tool_hugehelp.c
> env LC_ALL=C /usr/bin/nroff -man   | /usr/bin/perl
> ../../src/curl-7.54.0/src/mkhelp.pl ../../src/curl-7.54.0/docs/MANUAL
> >> tool_hugehelp.c 

I don't see what's wrong. What am I missing, where is the error? If this
is a new issue exclusive to 7.54 can you file it as a new issue
https://github.com/curl/curl/issues/new or start a new thread please.
---
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette:   https://curl.haxx.se/mail/etiquette.html

Re: possible patch release?

[Dan Fandrich]

On Fri, Apr 21, 2017 at 08:51:16AM +0200, Michael Felt wrote:
> On 22/02/2017 19:21, Michael Felt wrote:
> >On 22/02/2017 14:37, Jan Ehrhardt wrote:
> >>Daniel Stenberg in gmane.comp.web.curl.library (Wed, 22 Feb 2017
> >>08:16:42 +0100 (CET)):
> >>>Due to issue #1276 [1] that was reported within an hour of the 7.53.0
> >>>release,
> >>>we're contemplating a follow-up patch release. All opinions and
> >>>arguments for
> >>>or against are welcome.
> >>+1, as I said in the issue.
> >
> >Well, I am about to test build for AIX - but if I understand correctly
> 
> I never got around to finishing 7.53, but 7.54 has a build issue (with the
> docs).
> 
> Make dies (no input file? because of /bin/sh rather than /bin/bash syntax
> perhaps?) with:

We're discussing the issue in https://github.com/curl/curl/issues/1432. It's a
limitation in make—switching to GNU make is a workaround, as is (in some cases)
applying commit 5b4cbcf1 (but that has problems of its own).

>>> Dan
---
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette:   https://curl.haxx.se/mail/etiquette.html

Re: possible patch release?

[Michael Felt]

On 22/02/2017 19:21, Michael Felt wrote:

On 22/02/2017 14:37, Jan Ehrhardt wrote:

Daniel Stenberg in gmane.comp.web.curl.library (Wed, 22 Feb 2017
08:16:42 +0100 (CET)):
Due to issue #1276 [1] that was reported within an hour of the 
7.53.0 release,
we're contemplating a follow-up patch release. All opinions and 
arguments for

or against are welcome.

+1, as I said in the issue.


Well, I am about to test build for AIX - but if I understand correctly 


I never got around to finishing 7.53, but 7.54 has a build issue (with 
the docs).


Make dies (no input file? because of /bin/sh rather than /bin/bash 
syntax perhaps?) with:


Making all in src
echo '#include "tool_setup.h"' > tool_hugehelp.c
echo '#ifndef HAVE_LIBZ' >> tool_hugehelp.c
env LC_ALL=C /usr/bin/nroff -man   | /usr/bin/perl 
../../src/curl-7.54.0/src/mkhelp.pl ../../src/curl-7.54.0/docs/MANUAL >> 
tool_hugehelp.c


Regards,

Michael

p.s. - the summarized version (second call to make)

root@x064:[/data/prj/aixtools/curl-7.54.0]make
Making all in lib
make  all-am
Target "all-am" is up to date.
Making all in docs
Making all in libcurl
Making all in opts
Target "all" is up to date.
Target "all-am" is up to date.
Target "all" is up to date.
Making all in cmdline-opts
Target "all" is up to date.
Target "all-am" is up to date.
Target "all" is up to date.
Making all in src
echo '#include "tool_setup.h"' > tool_hugehelp.c
echo '#ifndef HAVE_LIBZ' >> tool_hugehelp.c
env LC_ALL=C /usr/bin/nroff -man   | /usr/bin/perl 
../../src/curl-7.54.0/src/mkhelp.pl ../../src/curl-7.54.0/docs/MANUAL >> 
tool_hugehelp.c


---
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette:   https://curl.haxx.se/mail/etiquette.html

Re: Static libcurl size under Windows

[Ray Satiro via curl-library]

On 4/20/2017 10:57 AM, Konstantin Vlasov wrote:
> I need static libcurl.lib which uses static OpenSSL but does NOT contain it as
> part of itself. Otherwise I would get link errors (symbol conflicts) when
> building VirtualBox with both libcurl AND openssl. The first scenario gave me
> exactly what I needed, but now in 7.54.0 it is deprecated. How do I get that
> type of libcurl.lib now?

Does anyone know why we're rolling all dependencies into static libcurl lib?
---
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette:   https://curl.haxx.se/mail/etiquette.html