> > I have a similar problem than the one described in > > https://sourceforge.net/tracker/?func=detail&atid=100976&aid=1779054&group_id=976 > > I honestly don't see many similarities between your problem and #1779054. > They're not the same. Ok, I trust you. > > I added a -ldl at the CFLAGS of the src/Makefile (by analogy with > > http://linuxfromscratch.org/pipermail/blfs-support/2006-August/060783.html) > > Funny, I've never needed -ldl with my openssl installs. I figure this means we > need to extend the OpenSSL checks in configure to check if it also needs > libdl! Just for eliminating any potential ambiguity, the file I modified is curl-7.17.0/src/Makefile. And the error occured with : gcc -g -g -W -Wall -Wwrite-strings -pedantic -Wpointer-arith -Wnested-externs -Winline -Wmissing-prototypes -Wmissing-declarations -Wundef -Wno-long-long -Wsign-compare -Wfloat-equal -Wno-format-nonliteral -Wendif-labels -Wstrict-prototypes -Wdeclaration-after-statement -isystem /home/eric/openssl-0.9.7m/include/openssl -isystem /home/eric/openssl-0.9.7m/include -o curl main.o hugehelp.o urlglob.o writeout.o writeenv.o getpass.o homedir.o curlutil.o strtoofft.o strdup.o -L/home/eric/openssl-0.9.7m/lib ../lib/.libs/libcurl.a -lssl -lcrypto -lz > > > /usr/bin/install -c -m 644 'curl.h' > > '/home/eric/curl-7.17.0/include/curl/curl.h' > > /usr/bin/install: `curl.h' et `/home/eric/curl-7.17.0/include/curl/curl.h' > > identifient le m?me fichier. > > > but it does not seem harmful. > > For us who're not overly good at French, what does it mean and why does it > happen? It looks like you're installing it to the same dir you built it in, is > that the case? > Sorry. "identifient le même fichier" means "identifies the same file". You are right, I installed curl in the same directory than I unpacked it. Obviously, it's a bad habit I should quit. > > I tried to reproduce this bug with a server of mine (ProFTPd, with > > self-signed certificate), by adding --limit-rate 30K to simulate a long > > server response, but without success > > 54 minutes, 37 seconds. > > Is this latter 54 minute case really going through the same network hoops as > the first 28 minute case does? > > This kind of behaviour is in 99.7% of all cases because you do this connection > over a firewall/NAT/router/whatever that times out "idle" connections after N > minutes and idleness and in your case I would say that N is greater than 13 > and that your latter case doesn't use the same network route as your first > case did. > For the test during 54 minutes, I indeed used an totally different network. The connection where the problem occurs indeed includes router, firewall and NAT equipment. Does this mean that, for this problem, there is no bug or any possible fix in curl and that it is only due to the network equipment ? A workaround would then be to chunk a file in smaller pieces, which, hopefully, I can do. Thanks, Eric LANDES _____________________________________________________________________________ Ne gardez plus qu'une seule adresse mail ! Copiez vos mails vers Yahoo! Mail
Received on 2007-09-20