Re: -T parameter on HP-UX port
Daniel Stenberg <[EMAIL PROTECTED]> writes: >> Would it make sense to simply always use this check? > > In my mind, this is what the function-exists test should do, but I > thought that I'd leave the existing test do what it thinks is right > first since there might be cases and systems around that works in > ways I haven't considered. For example, this extra test might fail > if the function name is defined as a macro. I think the existing tests already fail if the function name is defined as a macro. At least that was my experience some time ago, FWIW.
Re: -T parameter on HP-UX port
On Sat, 5 Jun 2004, Hrvoje Niksic wrote: > Believe it or not, I wasn't aware of that. Furthermore, I'm pretty certain > that older versions of Autoconf handled HPUX just fine. The level of > overengineering that went into Autoconf in the last several years is > appalling. :-( I agree with this, and I too am convinced that this used to work fine in the past and just suddenly stopped working at some point. > Would it make sense to simply always use this check? In my mind, this is what the function-exists test should do, but I thought that I'd leave the existing test do what it thinks is right first since there might be cases and systems around that works in ways I haven't considered. For example, this extra test might fail if the function name is defined as a macro. -- -=- Daniel Stenberg -=- http://daniel.haxx.se -=- ech`echo xiun|tr nu oc|sed 'sx\([sx]\)\([xoi]\)xo un\2\1 is xg'`ol
Re: -T parameter on HP-UX port
Daniel Stenberg <[EMAIL PROTECTED]> writes: > On Thu, 3 Jun 2004, Hrvoje Niksic wrote: > >> It seems configure's way of checking for select simply fails on HPUX. >> :-( > > The default configure test that checks for the presence of a > function is certainly not optimal for all platforms and > environments. Believe it or not, I wasn't aware of that. Furthermore, I'm pretty certain that older versions of Autoconf handled HPUX just fine. The level of overengineering that went into Autoconf in the last several years is appalling. :-( > In curl's configure script, we've resorted to a secondary check if > the default check fails, and that one detects select fine even in > cases like this. > > The concept is basicly like this: > > AC_CHECK_FUNCS( select, , > dnl if not found, $ac_func is the name we check for > func="$ac_func" > AC_MSG_CHECKING([deeper for $func]) > AC_TRY_LINK( [], >[ $func ();], >AC_MSG_RESULT(yes!) >eval "ac_cv_func_$func=yes" >def=`echo "HAVE_$func" | tr 'a-z' 'A-Z'` >AC_DEFINE_UNQUOTED($def, 1, [If you have $func]), >AC_MSG_RESULT(but still no) >) Would it make sense to simply always use this check?
Re: -T parameter on HP-UX port
On Thu, 3 Jun 2004, Hrvoje Niksic wrote: > It seems configure's way of checking for select simply fails on HPUX. > :-( The default configure test that checks for the presence of a function is certainly not optimal for all platforms and environments. In curl's configure script, we've resorted to a secondary check if the default check fails, and that one detects select fine even in cases like this. The concept is basicly like this: AC_CHECK_FUNCS( select, , dnl if not found, $ac_func is the name we check for func="$ac_func" AC_MSG_CHECKING([deeper for $func]) AC_TRY_LINK( [], [ $func ();], AC_MSG_RESULT(yes!) eval "ac_cv_func_$func=yes" def=`echo "HAVE_$func" | tr 'a-z' 'A-Z'` AC_DEFINE_UNQUOTED($def, 1, [If you have $func]), AC_MSG_RESULT(but still no) ) -- -=- Daniel Stenberg -=- http://daniel.haxx.se -=- ech`echo xiun|tr nu oc|sed 'sx\([sx]\)\([xoi]\)xo un\2\1 is xg'`ol
Re: -T parameter on HP-UX port
That's it. I just add the line '#define HAVE_SELECT 1' in the config.h file and re-compile. And all is working fine now. Thanks a lot for your support. Best regards Nicolas Varney Hrvoje Niksic <[EMAIL PROTECTED]> on 03/06/2004 09:53:08 To: Nicolas Varney/Interne/[EMAIL PROTECTED] cc: [EMAIL PROTECTED] Subject: Re: -T parameter on HP-UX port [EMAIL PROTECTED] writes: > For the second point. I didn't compile wget myself, I use the version published > on HP-UX Software Porting Center (http://hpux.connect.org.uk/) > So I get the official sources and HP-UX Software Porting Center sources and > compile both version. > > Results are the same. No time out occurs. The problem is that configure doesn't correctly detect the "select" system call: > configure:11676: checking for select > configure:11726: gcc -o conftest -O2 -Wall -Wno-implicit conftest.c >&5 > configure:11756: error: conflicting types for `select' > /usr/include/sys/time.h:489: error: previous declaration of `select' > configure:11729: $? = 1 > configure: failed program was: [...] > configure:11746: result: no It seems configure's way of checking for select simply fails on HPUX. :-( For now, you can edit `config.h' after running configure and simply change #undef HAVE_SELECT to #define HAVE_SELECT 1. If the compilation works, the timeout should work again.
Re: -T parameter on HP-UX port
[EMAIL PROTECTED] writes: > For the second point. I didn't compile wget myself, I use the version published > on HP-UX Software Porting Center (http://hpux.connect.org.uk/) > So I get the official sources and HP-UX Software Porting Center sources and > compile both version. > > Results are the same. No time out occurs. The problem is that configure doesn't correctly detect the "select" system call: > configure:11676: checking for select > configure:11726: gcc -o conftest -O2 -Wall -Wno-implicit conftest.c >&5 > configure:11756: error: conflicting types for `select' > /usr/include/sys/time.h:489: error: previous declaration of `select' > configure:11729: $? = 1 > configure: failed program was: [...] > configure:11746: result: no It seems configure's way of checking for select simply fails on HPUX. :-( For now, you can edit `config.h' after running configure and simply change #undef HAVE_SELECT to #define HAVE_SELECT 1. If the compilation works, the timeout should work again.
Re: -T parameter on HP-UX port
[EMAIL PROTECTED] writes: > Here is a trace of system calls during execution of 'wget -t 1 -T 10 > http://www.admin.edt.fr/supervision/test.jsp' > > (See attached file: wget_trace.txt) Thanks. Apparently Wget isn't even calling select! I see two possibilities: 1. Something in your configuration prevents -T to be recognized. Do you have a `.wgetrc' file, or perhaps `/usr/local/etc/wgetrc'? (Command-line arguments should override .wgetrc options, but bugs happen.) 2. Wget didn't detect a "select" system call on your system. Do you compile Wget yourself? If so, could you send the output of `configure'? If not, could you try compiling Wget yourself and see if that makes the problem go away?
Re: -T parameter on HP-UX port
[EMAIL PROTECTED] writes: > Here is the result of "wget -t 1 -T 10 -d > http://www.admin.edt.fr/supervision/test.jsp"; command on HP-UX with version > 1.8.1 and 1.9.1 > With version 1.9.1, time out never occurs I'm not aware of significant differences between the two versions in that department. Could you send a system call trace so we can see what Wget is doing?
Re: -T parameter on HP-UX port
Here is the result of "wget -t 1 -T 10 -d http://www.admin.edt.fr/supervision/test.jsp"; command on HP-UX with version 1.8.1 and 1.9.1 With version 1.9.1, time out never occurs See below Best regards Nicolas Varney A test with wget 1.8.1 on HP-UX : # wget -t 1 -T 10 -d http://www.admin.edt.fr/supervision/test.jsp DEBUG output created by Wget 1.8.1 on hpux11.00. --09:30:37-- http://www.admin.edt.fr/supervision/test.jsp => `test.jsp' Resolving www.admin.edt.fr... done. Caching www.admin.edt.fr => 217.167.17.27 217.167.17.28 Connecting to www.admin.edt.fr[217.167.17.27]:80... connected. Created socket 3. Releasing 4000bfb0 (new refcount 1). ---request begin--- GET /supervision/test.jsp HTTP/1.0 User-Agent: Wget/1.8.1 Host: www.admin.edt.fr Accept: */* Connection: Keep-Alive ---request end--- HTTP request sent, awaiting response... Read error (Connection timed out) in headers. Closing fd 3 Giving up. The same test with wget 1.9.1 # wget -t 1 -T 10 -d http://www.admin.edt.fr/supervision/test.jsp DEBUG output created by Wget 1.9.1 on hpux11.00. --09:29:03-- http://www.admin.edt.fr/supervision/test.jsp => `test.jsp' Resolving www.admin.edt.fr... 217.167.17.27, 217.167.17.28 Caching www.admin.edt.fr => 217.167.17.27 217.167.17.28 Connecting to www.admin.edt.fr[217.167.17.27]:80... connected. Created socket 3. Releasing 4001c7c0 (new refcount 1). ---request begin--- GET /supervision/test.jsp HTTP/1.0 User-Agent: Wget/1.9.1 Host: www.admin.edt.fr Accept: */* Connection: Keep-Alive ---request end--- HTTP request sent, awaiting response...
Re: -T parameter on HP-UX port
[EMAIL PROTECTED] writes: > On platform HP-UX 11.00 PA-RISC > wget version 1.9.1 > -T parameter not work in a certain condition > > On a deadly HTTP server (HTTP server accept connection, but never send data) > wget wait indefinitely Could you post a debug log or (better) trace output?
-T parameter on HP-UX port
On platform HP-UX 11.00 PA-RISC wget version 1.9.1 -T parameter not work in a certain condition On a deadly HTTP server (HTTP server accept connection, but never send data) wget wait indefinitely Regards Nicolas Varney
