Re: Asiohiper example program delay

[Daniel Stenberg]

On Fri, 18 May 2018, Sean Miller wrote:

Does it seem like that could be what happens in your case? If so, I'll 
write up a patch you can test...


I'd be happy to test a patch. I've been poking around in the code a little 
myself, but I'm unfamiliar with it.


I've reproduced this on libcurl-7.19.7 (RHEL6... I know...) and 
libcurl-7.55.1, the latter of which I build myself.


Hi again, sorry it took me while to get back but attached here is a debug 
patch that I'd like you to apply to your code and see what debug output (and 
possibly changed behavior) you get. Please do another log and attach in a 
reply.


I think might be easiest if you build 7.60.0 (or just git master) from source 
if we need to try out further stuff, but I won't insist on putting that on 
you. It would also reduce the risk that you're actually seeing the effects of 
a bug we've already fixed or subtly changed since 7.55.1...


--

 / daniel.haxx.seFrom a03eb7f616218c207b662868fbdc2579a2c8a35a Mon Sep 17 00:00:00 2001
From: Daniel Stenberg 
Date: Thu, 24 May 2018 00:21:37 +0200
Subject: [PATCH] debug: Curl_protocol_getsock

---
 lib/url.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/lib/url.c b/lib/url.c
index 701f83ab3..fdb84267b 100644
--- a/lib/url.c
+++ b/lib/url.c
@@ -1552,11 +1552,14 @@ int Curl_protocol_getsock(struct connectdata *conn,
   curl_socket_t *socks,
   int numsocks)
 {
   if(conn->handler->proto_getsock)
 return conn->handler->proto_getsock(conn, socks, numsocks);
-  return GETSOCK_BLANK;
+  infof(conn->data, "%s:%d => debug point\n",
+__FILE__, __LINE__);
+  socks[0] = conn->sock[FIRSTSOCKET];
+  return GETSOCK_READSOCK(0) | GETSOCK_WRITESOCK(0);
 }
 
 int Curl_doing_getsock(struct connectdata *conn,
curl_socket_t *socks,
int numsocks)
-- 
2.17.0

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

Re: Assigning "sub maintainers" for Windows and cmake!

[René Berber]

On 5/23/2018 1:13 AM, Daniel Stenberg wrote:

[snip]
> I'm more concerned about problems with code that is well used and that
> we get issues and PRs filed about, but there's no maintainer around to
> give solid advice, merge code etc for.

Exactly the main point.  Porting (to Windows in this case) is the main
issue, building environments is secondary and, since many work fine, not
even an important issue.

Like many others have said for their case... I use MXE, which is a
cross-build environment that usually targets Windows, their maintainers
(and users) keep track of what works, and if not, what's needed, usually
small patches.  If one of those patches did change curl's source, it
will be sent upstream (trying to keep things as clean as possible in MXE
itself).

So this is a use case that uses Unix/Linux tools (also can be used under
Cygwin/Windows, or OSX) and gets results.  Currently for curl it uses
the configure way, but it can use cmake (and it does for other
packages).  Side note: it has the advantage that you can further
customize your build, I use my own curl+cares recipe.
-- 
R. Berber
---
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette:   https://curl.haxx.se/mail/etiquette.html

Re: SMB: unable to upload file to a subfolder: remote file not found

[Gisle Vanem]

Ivan Pilipenko wrote:


Also, it seems that SMB1 support is being phased out (disabled starting with
win10 1709, apparently), so sadly, in its current state it means that we can
not use curl for SMB support.


True, but you could just reinstall SMBv1 by running:
  c:\Windows\Sysnative\OptionalFeatures.exe

Or as described here:
  https://www.youtube.com/watch?v=uI1KpdqNpP4


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

Re: SMB: unable to upload file to a subfolder: remote file not found

[Ivan Pilipenko]

> Daniel Stenberg  hat am 23. Mai 2018 um 13:24 geschrieben:
> 
> 
> On Tue, 22 May 2018, Ivan Pilipenko wrote:
> 
> > - using curl and empty credentials, I can put files into root, but not into 
> > folders created by smbclient
> 
> > - using curl and valid credentials, I can't even log in: I am getting 
> > "login 
> > denied (67)"
> >
> > I am using the same credentials for smbclient and curl (the binary package 
> > of the OS, as well as libcurl + my implementation), so I expected them to 
> > at 
> > least behave the same.
> 
> I would have expected that as well. I'm not very familiar with the SMB 
> protocol so I'm not much of a help with this, but I would suggest that you 
> build a debug version of curl, sprinkle it with printf() outputs or similar 
> and start figuring out where it goes wrong...
> 
> -- 
> 
>   / daniel.haxx.se

Well, the "login denied" error stems from the fact curl does not support NTLMv2
(according to your TODO list), and all our samba servers do not allow using
anything below that

Also, it seems that SMB1 support is being phased out (disabled starting with 
win10 1709, apparently), so sadly, in its current state it means that we can
not use curl for SMB support.

Thank you for your help!

-- 
Freundliche Grüße / Best regards
Ivan Pilipenko
-
Upcoming Events:
19.-22. June: AUTOMATICA, Munich, Germany
06.-08. November: VISION, Stuttgart, Germany 
-

MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler
Registergericht: Amtsgericht Stuttgart, HRB 271090
Geschaeftsfuehrer: Uwe Furtner

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

Re: SMB: unable to upload file to a subfolder: remote file not found

[Daniel Stenberg]

On Tue, 22 May 2018, Ivan Pilipenko wrote:

- using curl and empty credentials, I can put files into root, but not into 
folders created by smbclient


- using curl and valid credentials, I can't even log in: I am getting "login 
denied (67)"


I am using the same credentials for smbclient and curl (the binary package 
of the OS, as well as libcurl + my implementation), so I expected them to at 
least behave the same.


I would have expected that as well. I'm not very familiar with the SMB 
protocol so I'm not much of a help with this, but I would suggest that you 
build a debug version of curl, sprinkle it with printf() outputs or similar 
and start figuring out where it goes wrong...


--

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

Re: Assigning "sub maintainers" for Windows and cmake!

[Daniel Stenberg]

On Wed, 23 May 2018, Sergei Nikulov wrote:


 message(WARNING "the curl cmake build system is poorly maintained.


We already tried multiple times to remove this message, but Daniel still 
objects those changes :)


But do you consider that line to be wrong ?

I think our 9 open cmake issues basically prove me right. And its not like 
these nine issues are a new problem that just appeared. Our cmake issues often 
take a long time to get fixed in our project.


The cmake build works perfectly for a whole bunch of users and that's fine and 
good, but there's no doubt in my mind that if you run into problems with it 
you're up for a rougher ride than with some of the other build options we 
have. Plus the fact that the cmake build is far from as feature-complete as 
the configure build is.


--

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

Re: Assigning "sub maintainers" for Windows and cmake!

[Sergei Nikulov]

ср, 23 мая 2018 г. в 11:49, Richard Alcock :

> On 23 May 2018 at 07:25, David Weisgerber 
wrote:
> > IMHO I would think about dropping some build systems in favor of cmake
because
> > it works well for Windows and Linux builds and you have to maintain
less.

> The big thing that put me off using CMake was this:

>  message(WARNING "the curl cmake build system is poorly maintained.
> Be aware")

> (from
https://github.com/curl/curl/blob/09d16af49a07af14dd635e23cdd6a0d287e54e54/CMakeLists.txt#L50
)


We already tried multiple times to remove this message, but Daniel still
objects those changes :)
That's why email with this subject appears here.

-- 
Best Regards,
Sergei Nikulov

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

Re: Assigning "sub maintainers" for Windows and cmake!

[Richard Alcock]

On 23 May 2018 at 07:25, David Weisgerber  wrote:
> IMHO I would think about dropping some build systems in favor of cmake because
> it works well for Windows and Linux builds and you have to maintain less.

The big thing that put me off using CMake was this:

message(WARNING "the curl cmake build system is poorly maintained.
Be aware")

(from 
https://github.com/curl/curl/blob/09d16af49a07af14dd635e23cdd6a0d287e54e54/CMakeLists.txt#L50)


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

Re: Assigning "sub maintainers" for Windows and cmake!

[Sergei Nikulov]

ср, 23 мая 2018 г. в 8:56, Kees Dekker :

> >
> > > 1. solution files
> > > 2. cmake
> > > 3. nmake
> >
> > and...
> >
> >4. configure (msys/mingw)
> >5. Borland makefiles
> >6. mingw makefiles
> >
> > > I understand that 'everybody is liking his own preferred method' (in
my
> > case
> > > #3), but it also makes that the few maintainers/contributors
available only
> > > check one or probably 2 out of 3 available methods. That is
encouraging
> > > inefficiency in my opinion. I know, that if someone decides to flavor
one of
> > > these 3, I may also suffer from dropping the other two.
> >
> > My hope was always that one of them would eventually grow up to be "the
> > winner", but that simply never happened. And it's not likely to
actually ever
> > happen. I actually don't think the build system plethora is such a big
> > problem, they mostly work.
> >
> > If we would drop build systems from the list above, it would make the
most
> > sense to drop 1, 3, 5 and 6 I think, leaving configure and cmake. I
just don't
> > think we would make many users happy today or tomorrow if we'd make
> > that
> > announcement.
> >

> I'm both working on *NIX and Windows, and from that point of view I
understand your preference of dropping 1,3,5,6.
> However, from Windows point of view, 1,3 are THE native visual studio
ones. That native ones are usually preferred by Windows developers
> (but again: correct me if I'm wrong) as using/building cURL is not an end
in itself. In most cases, curl is a part of a larger whole.
> Windows developers are using curl as part of whatever (IMO usually). For
that reason, the build procedure of curl need to
> match or incorporated in some way with a larger whole, i.e. the code base
of the adopting party. If a adopting party does not use
> none of the 'non-visual-studio' methods, the others make not much sense.
Of course, if someone uses 'one of the others', they can
> say the same for the visual studio-based methods.

> I think - but that is a wild guess of me - the *NIX look-alikes on
Windows systems are being used because their organization forces

> to use a Windows system (laptop or desktop) but the end-users love the
UNIX world, and thus use something like mingw/Cygwin (=4,6).
> Their actual need is a Linux system, but that one does not offer
Microsoft office. Borland is something from very long time ago (30+ years)
for me.

Just FYI, CMake able to generate 1,3,5,6
https://cmake.org/cmake/help/v3.0/manual/cmake-generators.7.html
So you can use nmake after the cmake -G"NMake Makefiles" invocation.

-- 
Best Regards,
Sergei Nikulov

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

Re: Assigning "sub maintainers" for Windows and cmake!

[David Weisgerber]

Hi,
my company is working mainly on a MFC based product with Visual Studio 
2010/2015. Some years ago we switched our build system to cmake and we now 
generate Visual Studio files from cmake. For us this has a lot of benefits.
I also built the last libcurl versions with cmake (though it has some bugs) 
because I think it is a lot easier and less error prone than using Visual 
Studio files where you have to edit a lot in order to find the correct 
libraries.
IMHO I would think about dropping some build systems in favor of cmake because 
it works well for Windows and Linux builds and you have to maintain less.

Best regards,
David

Am Mittwoch, 23. Mai 2018, 07:53:34 CEST schrieb Kees Dekker:
> > > 1. solution files
> > > 2. cmake
> > > 3. nmake
> > 
> > and...
> > 
> >4. configure (msys/mingw)
> >5. Borland makefiles
> >6. mingw makefiles
> > > 
> > > I understand that 'everybody is liking his own preferred method' (in my
> > 
> > case
> > 
> > > #3), but it also makes that the few maintainers/contributors available
> > > only
> > > check one or probably 2 out of 3 available methods. That is encouraging
> > > inefficiency in my opinion. I know, that if someone decides to flavor
> > > one of these 3, I may also suffer from dropping the other two.
> > 
> > My hope was always that one of them would eventually grow up to be "the
> > winner", but that simply never happened. And it's not likely to actually
> > ever happen. I actually don't think the build system plethora is such a
> > big problem, they mostly work.
> > 
> > If we would drop build systems from the list above, it would make the most
> > sense to drop 1, 3, 5 and 6 I think, leaving configure and cmake. I just
> > don't think we would make many users happy today or tomorrow if we'd make
> > that
> > announcement.
> 
> I'm both working on *NIX and Windows, and from that point of view I
> understand your preference of dropping 1,3,5,6. However, from Windows point
> of view, 1,3 are THE native visual studio ones. That native ones are
> usually preferred by Windows developers (but again: correct me if I'm
> wrong) as using/building cURL is not an end in itself. In most cases, curl
> is a part of a larger whole. Windows developers are using curl as part of
> whatever (IMO usually). For that reason, the build procedure of curl need
> to match or incorporated in some way with a larger whole, i.e. the code
> base of the adopting party. If a adopting party does not use none of the
> 'non-visual-studio' methods, the others make not much sense. Of course, if
> someone uses 'one of the others', they can say the same for the visual
> studio-based methods.
> 
> I think - but that is a wild guess of me - the *NIX look-alikes on Windows
> systems are being used because their organization forces to use a Windows
> system (laptop or desktop) but the end-users love the UNIX world, and thus
> use something like mingw/Cygwin (=4,6). Their actual need is a Linux
> system, but that one does not offer Microsoft office. Borland is something
> from very long time ago (30+ years) for me.
> 
> I will try to contribute where I can, and really prefer 1 or 3 (we are now
> using 3 and calling nmake from within another project file).
> 
> ---
> Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
> Etiquette:   https://curl.haxx.se/mail/etiquette.html




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

RE: Assigning "sub maintainers" for Windows and cmake!

[Daniel Stenberg]

On Wed, 23 May 2018, Kees Dekker wrote:

If we would drop build systems from the list above, it would make the most 
sense to drop 1, 3, 5 and 6 I think, leaving configure and cmake. I just 
don't think we would make many users happy today or tomorrow if we'd make 
that announcement.


I'm both working on *NIX and Windows, and from that point of view I 
understand your preference of dropping 1,3,5,6. However, from Windows point 
of view, 1,3 are THE native visual studio ones. That native ones are usually 
preferred by Windows developers (but again: correct me if I'm wrong) as 
using/building cURL is not an end in itself. In most cases, curl is a part 
of a larger whole. Windows developers are using curl as part of whatever 
(IMO usually). For that reason, the build procedure of curl need to match or 
incorporated in some way with a larger whole, i.e. the code base of the 
adopting party.


Sure, and that's exactly the line of reasoning everyone will have for why 
their particular build system should remain. They use it, they know it and it 
works for them.


I didn't seriously mean we would remove those.

My personal take on multiple build options is the same as supporting every OS 
or architecture under the sun: let those who use that system fix it if there's 
something wrong.


If we all polish and improve the code and scripts we use, things that are used 
will grow better over time and things that aren't used... well if they aren't 
used it doesn't matter too much if those areas fall behind a bit.


I'm more concerned about problems with code that is well used and that we get 
issues and PRs filed about, but there's no maintainer around to give solid 
advice, merge code etc for.


--

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

RE: Assigning "sub maintainers" for Windows and cmake!

[Kees Dekker]

> 
> > 1. solution files
> > 2. cmake
> > 3. nmake
> 
> and...
> 
>4. configure (msys/mingw)
>5. Borland makefiles
>6. mingw makefiles
> 
> > I understand that 'everybody is liking his own preferred method' (in my
> case
> > #3), but it also makes that the few maintainers/contributors available only
> > check one or probably 2 out of 3 available methods. That is encouraging
> > inefficiency in my opinion. I know, that if someone decides to flavor one of
> > these 3, I may also suffer from dropping the other two.
> 
> My hope was always that one of them would eventually grow up to be "the
> winner", but that simply never happened. And it's not likely to actually ever
> happen. I actually don't think the build system plethora is such a big
> problem, they mostly work.
> 
> If we would drop build systems from the list above, it would make the most
> sense to drop 1, 3, 5 and 6 I think, leaving configure and cmake. I just don't
> think we would make many users happy today or tomorrow if we'd make
> that
> announcement.
> 

I'm both working on *NIX and Windows, and from that point of view I understand 
your preference of dropping 1,3,5,6.
However, from Windows point of view, 1,3 are THE native visual studio ones. 
That native ones are usually preferred by Windows developers
(but again: correct me if I'm wrong) as using/building cURL is not an end in 
itself. In most cases, curl is a part of a larger whole.
Windows developers are using curl as part of whatever (IMO usually). For that 
reason, the build procedure of curl need to
match or incorporated in some way with a larger whole, i.e. the code base of 
the adopting party. If a adopting party does not use
none of the 'non-visual-studio' methods, the others make not much sense. Of 
course, if someone uses 'one of the others', they can
say the same for the visual studio-based methods.

I think - but that is a wild guess of me - the *NIX look-alikes on Windows 
systems are being used because their organization forces
to use a Windows system (laptop or desktop) but the end-users love the UNIX 
world, and thus use something like mingw/Cygwin (=4,6).
Their actual need is a Linux system, but that one does not offer Microsoft 
office. Borland is something from very long time ago (30+ years) for me.

I will try to contribute where I can, and really prefer 1 or 3 (we are now 
using 3 and calling nmake from within another project file).

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