Build failed in Hudson: 3.HEAD-i386-opensolaris #417
See http://build.squid-cache.org/job/3.HEAD-i386-opensolaris/417/changes Changes: [Amos Jeffries amosjeffr...@squid-cache.org] Sync dist languages with .po -- [...truncated 3486 lines...] /usr/sfw/lib/gcc/i386-pc-solaris2.11/3.4.3/../../../../include/c++/3.4.3/cwchar:176: error: `::wcrtomb' has not been declared /usr/sfw/lib/gcc/i386-pc-solaris2.11/3.4.3/../../../../include/c++/3.4.3/cwchar:187: error: `::wcsrtombs' has not been declared /usr/sfw/lib/gcc/i386-pc-solaris2.11/3.4.3/../../../../include/c++/3.4.3/cwchar:197: error: `::wctob' has not been declared /usr/sfw/lib/gcc/i386-pc-solaris2.11/3.4.3/../../../../include/c++/3.4.3/cwchar:198: error: `::wmemcmp' has not been declared /usr/sfw/lib/gcc/i386-pc-solaris2.11/3.4.3/../../../../include/c++/3.4.3/cwchar:199: error: `::wmemcpy' has not been declared /usr/sfw/lib/gcc/i386-pc-solaris2.11/3.4.3/../../../../include/c++/3.4.3/cwchar:200: error: `::wmemmove' has not been declared /usr/sfw/lib/gcc/i386-pc-solaris2.11/3.4.3/../../../../include/c++/3.4.3/cwchar:201: error: `::wmemset' has not been declared /usr/sfw/lib/gcc/i386-pc-solaris2.11/3.4.3/../../../../include/c++/3.4.3/cwchar:202: error: `::wprintf' has not been declared /usr/sfw/lib/gcc/i386-pc-solaris2.11/3.4.3/../../../../include/c++/3.4.3/cwchar:203: error: `::wscanf' has not been declared /usr/sfw/lib/gcc/i386-pc-solaris2.11/3.4.3/../../../../include/c++/3.4.3/cwchar:223: error: `::wcsstr' has not been declared /usr/sfw/lib/gcc/i386-pc-solaris2.11/3.4.3/../../../../include/c++/3.4.3/cwchar: In function `wchar_t* std::wcsstr(wchar_t*, const wchar_t*)': /usr/sfw/lib/gcc/i386-pc-solaris2.11/3.4.3/../../../../include/c++/3.4.3/cwchar:227: error: invalid conversion from `const wchar_t*' to `wchar_t*' /usr/sfw/lib/gcc/i386-pc-solaris2.11/3.4.3/../../../../include/c++/3.4.3/cwchar:227: error: initializing argument 1 of `wchar_t* std::wcsstr(wchar_t*, const wchar_t*)' /usr/sfw/lib/gcc/i386-pc-solaris2.11/3.4.3/../../../../include/c++/3.4.3/cwchar: At global scope: /usr/sfw/lib/gcc/i386-pc-solaris2.11/3.4.3/../../../../include/c++/3.4.3/cwchar:229: error: `::wmemchr' has not been declared /usr/sfw/lib/gcc/i386-pc-solaris2.11/3.4.3/../../../../include/c++/3.4.3/cwchar: In function `wchar_t* std::wmemchr(wchar_t*, wchar_t, size_t)': /usr/sfw/lib/gcc/i386-pc-solaris2.11/3.4.3/../../../../include/c++/3.4.3/cwchar:233: error: invalid conversion from `const wchar_t*' to `wchar_t*' /usr/sfw/lib/gcc/i386-pc-solaris2.11/3.4.3/../../../../include/c++/3.4.3/cwchar:233: error: initializing argument 1 of `wchar_t* std::wmemchr(wchar_t*, wchar_t, size_t)' In file included from /usr/sfw/lib/gcc/i386-pc-solaris2.11/3.4.3/../../../../include/c++/3.4.3/ios:46, from /usr/sfw/lib/gcc/i386-pc-solaris2.11/3.4.3/../../../../include/c++/3.4.3/ostream:45, from ../../../src/ip/Address.h:61, from ../../../src/squid.h:171, from ../../../src/base/AsyncCall.cc:5: /usr/sfw/lib/gcc/i386-pc-solaris2.11/3.4.3/../../../../include/c++/3.4.3/bits/char_traits.h: In static member function `static int std::char_traitswchar_t::compare(const wchar_t*, const wchar_t*, size_t)': /usr/sfw/lib/gcc/i386-pc-solaris2.11/3.4.3/../../../../include/c++/3.4.3/bits/char_traits.h:324: error: `wmemcmp' undeclared (first use this function) /usr/sfw/lib/gcc/i386-pc-solaris2.11/3.4.3/../../../../include/c++/3.4.3/bits/char_traits.h:324: error: (Each undeclared identifier is reported only once for each function it appears in.) /usr/sfw/lib/gcc/i386-pc-solaris2.11/3.4.3/../../../../include/c++/3.4.3/bits/char_traits.h: In static member function `static const wchar_t* std::char_traitswchar_t::find(const wchar_t*, size_t, const wchar_t)': /usr/sfw/lib/gcc/i386-pc-solaris2.11/3.4.3/../../../../include/c++/3.4.3/bits/char_traits.h:332: error: invalid conversion from `const wchar_t*' to `wchar_t*' /usr/sfw/lib/gcc/i386-pc-solaris2.11/3.4.3/../../../../include/c++/3.4.3/bits/char_traits.h:332: error: initializing argument 1 of `wchar_t* std::wmemchr(wchar_t*, wchar_t, size_t)' /usr/sfw/lib/gcc/i386-pc-solaris2.11/3.4.3/../../../../include/c++/3.4.3/bits/char_traits.h: In static member function `static wchar_t* std::char_traitswchar_t::move(wchar_t*, const wchar_t*, size_t)': /usr/sfw/lib/gcc/i386-pc-solaris2.11/3.4.3/../../../../include/c++/3.4.3/bits/char_traits.h:336: error: `wmemmove' undeclared (first use this function) /usr/sfw/lib/gcc/i386-pc-solaris2.11/3.4.3/../../../../include/c++/3.4.3/bits/char_traits.h: In static member function `static wchar_t* std::char_traitswchar_t::copy(wchar_t*, const wchar_t*, size_t)': /usr/sfw/lib/gcc/i386-pc-solaris2.11/3.4.3/../../../../include/c++/3.4.3/bits/char_traits.h:340: error: `wmemcpy' undeclared (first use this function) /usr/sfw/lib/gcc/i386-pc-solaris2.11/3.4.3/../../../../include/c++/3.4.3/bits/char_traits.h: In static member function `static wchar_t*
auth_param ntlm keep_alive interaction with new http/1.1 keepalive behaviour
G'day, Today I had a report of a problem seen with a late version of 3.1.6 + http/1.1, chunked response and keepalive patches. The problem occurs in the following situation. Laptop is on domain ONE, user bob. Proxy is on domain TWO, and accepts user alice. What happens with an older version of squid (with no auth_param ntlm keep_alive line in the config) is this: GET 407, NTLM GET, NTLM hash 407, NTLM hash GET, NTLM hash for ONE/bob *** 407 NTLM, Proxy-Connection: Close *** (connection torn down and re-established at this point) GET 407, NTLM GET, NTLM hash 407, NTLM hash GET, NTLM hash for TWO/alice 200 OK What happens with newer code that does http/1.1 with more aggresive keep-alive: GET 407 NTLM GET, NTLM hash 407 NTLM hash GET, NTLM hash for ONE/bob *** 407 NTLM Proxy-Connection: keep-alive GET 407, NTLM GET, NTLM hash 407, NTLM hash GET, NTLM hash for TWO/alice 200 OK *** marks the lines that are different between the two exchanges. The behaviour seen by the user in the latter case above is many authentication dialogs in firefox(3.6.x), approximately 1 per proxy-connection established. Setting auth_param ntlm keep_alive off causes the user's authentication dialogs to stop appearing. Perhaps with 3.1.7 or 3.2 we should consider defaulting to ntlm keep_alive off. -- Regards, Stephen Thorne Development Engineer Netbox Blue
Re: auth_param ntlm keep_alive interaction with new http/1.1 keepalive behaviour
Stephen Thorne wrote: G'day, Today I had a report of a problem seen with a late version of 3.1.6 + http/1.1, chunked response and keepalive patches. The problem occurs in the following situation. Laptop is on domain ONE, user bob. Proxy is on domain TWO, and accepts user alice. What happens with an older version of squid (with no auth_param ntlm keep_alive line in the config) is this: GET 407, NTLM GET, NTLM hash 407, NTLM hash GET, NTLM hash for ONE/bob *** 407 NTLM, Proxy-Connection: Close *** (connection torn down and re-established at this point) GET 407, NTLM GET, NTLM hash 407, NTLM hash GET, NTLM hash for TWO/alice 200 OK What happens with newer code that does http/1.1 with more aggresive keep-alive: GET 407 NTLM GET, NTLM hash 407 NTLM hash GET, NTLM hash for ONE/bob *** 407 NTLM Proxy-Connection: keep-alive GET 407, NTLM GET, NTLM hash 407, NTLM hash GET, NTLM hash for TWO/alice 200 OK *** marks the lines that are different between the two exchanges. The behaviour seen by the user in the latter case above is many authentication dialogs in firefox(3.6.x), approximately 1 per proxy-connection established. Setting auth_param ntlm keep_alive off causes the user's authentication dialogs to stop appearing. Perhaps with 3.1.7 or 3.2 we should consider defaulting to ntlm keep_alive off. The 'new' behaviour you are seeing as I understand it is correct NTLM persistent connection behaviour. Although the popup-per-connection is a bit extreme, its probably caused by race condition in firefox between parallel connections being rejected vs the new credentials being confirmed. Please report it to the firefox people as well, they need to fix that user-annoying behaviour regardless of what we do. off is the only setting for keep_alive of NTLM and Negotiate configs which has done anything. In both cases it has always acted as a hack/workaround to force closed the connection immediately after Squid offers its range of possible auth methods to the browser. fixing interactions between Squid with NTLM and broken servers and clients. PS. Does this occur with IE? IMO we can take that browser as the benchmark for NTLM. Amos -- Please be using Current Stable Squid 2.7.STABLE9 or 3.1.6 Beta testers wanted for 3.2.0.1
perhaps OT: problem compiling 3.1.6 on SLES10-SP3
Hi, maintaining the squid3 RPM on build.openuse.org. 3.1.4 was the last version I was able to compile without problems. for 3.1.5 I need to apply a small patch. (squid-bootstrap.patch) since 3.1.6 I not able to compile it for SLES10-SP3 while using ... snip spec %build export CFLAGS=$RPM_OPT_FLAGS -fPIE -fPIC -fno-strict-aliasing export CXXFLAGS=$RPM_OPT_FLAGS -fPIC -fno-strict-aliasing export LDFLAGS='-pie' ./bootstrap.sh autoreconf -fiv ./configure --prefix=/usr \ -snip I get: + ./bootstrap.sh automake (1.9) : automake autoconf (2.59) : autoconf libtool (1.5) : libtool libtool path : /usr/bin Bootstrapping compat/Makefile.am:12: Libtool library used but `LIBTOOL' is undefined compat/Makefile.am:12: compat/Makefile.am:12: The usual way to define `LIBTOOL' is to add `AC_PROG_LIBTOOL' compat/Makefile.am:12: to `configure.in' and run `aclocal' and `autoconf' again. src/Makefile.am:153: Libtool library used but `LIBTOOL' is undefined src/Makefile.am:153: src/Makefile.am:153: The usual way to define `LIBTOOL' is to add `AC_PROG_LIBTOOL' src/Makefile.am:153: to `configure.in' and run `aclocal' and `autoconf' again. src/acl/Makefile.am:4: Libtool library used but `LIBTOOL' is undefined src/acl/Makefile.am:4: src/acl/Makefile.am:4: The usual way to define `LIBTOOL' is to add `AC_PROG_LIBTOOL' src/acl/Makefile.am:4: to `configure.in' and run `aclocal' and `autoconf' again. src/adaptation/Makefile.am:15: Libtool library used but `LIBTOOL' is undefined src/adaptation/Makefile.am:15: src/adaptation/Makefile.am:15: The usual way to define `LIBTOOL' is to add `AC_PROG_LIBTOOL' src/adaptation/Makefile.am:15: to `configure.in' and run `aclocal' and `autoconf' again. src/adaptation/ecap/Makefile.am:4: Libtool library used but `LIBTOOL' is undefined src/adaptation/ecap/Makefile.am:4: src/adaptation/ecap/Makefile.am:4: The usual way to define `LIBTOOL' is to add `AC_PROG_LIBTOOL' src/adaptation/ecap/Makefile.am:4: to `configure.in' and run `aclocal' and `autoconf' again. src/adaptation/icap/Makefile.am:4: Libtool library used but `LIBTOOL' is undefined src/adaptation/icap/Makefile.am:4: src/adaptation/icap/Makefile.am:4: The usual way to define `LIBTOOL' is to add `AC_PROG_LIBTOOL' src/adaptation/icap/Makefile.am:4: to `configure.in' and run `aclocal' and `autoconf' again. src/auth/Makefile.am:7: Libtool library used but `LIBTOOL' is undefined src/auth/Makefile.am:7: src/auth/Makefile.am:7: The usual way to define `LIBTOOL' is to add `AC_PROG_LIBTOOL' src/auth/Makefile.am:7: to `configure.in' and run `aclocal' and `autoconf' again. src/base/Makefile.am:5: Libtool library used but `LIBTOOL' is undefined src/base/Makefile.am:5: src/base/Makefile.am:5: The usual way to define `LIBTOOL' is to add `AC_PROG_LIBTOOL' src/base/Makefile.am:5: to `configure.in' and run `aclocal' and `autoconf' again. src/esi/Makefile.am:4: Libtool library used but `LIBTOOL' is undefined src/esi/Makefile.am:4: src/esi/Makefile.am:4: The usual way to define `LIBTOOL' is to add `AC_PROG_LIBTOOL' src/esi/Makefile.am:4: to `configure.in' and run `aclocal' and `autoconf' again. src/fs/Makefile.am:3: Libtool library used but `LIBTOOL' is undefined src/fs/Makefile.am:3: src/fs/Makefile.am:3: The usual way to define `LIBTOOL' is to add `AC_PROG_LIBTOOL' src/fs/Makefile.am:3: to `configure.in' and run `aclocal' and `autoconf' again. src/icmp/Makefile.am:25: Libtool library used but `LIBTOOL' is undefined src/icmp/Makefile.am:25: src/icmp/Makefile.am:25: The usual way to define `LIBTOOL' is to add `AC_PROG_LIBTOOL' src/icmp/Makefile.am:25: to `configure.in' and run `aclocal' and `autoconf' again. src/ident/Makefile.am:4: Libtool library used but `LIBTOOL' is undefined src/ident/Makefile.am:4: src/ident/Makefile.am:4: The usual way to define `LIBTOOL' is to add `AC_PROG_LIBTOOL' src/ident/Makefile.am:4: to `configure.in' and run `aclocal' and `autoconf' again. src/ip/Makefile.am:4: Libtool library used but `LIBTOOL' is undefined src/ip/Makefile.am:4: src/ip/Makefile.am:4: The usual way to define `LIBTOOL' is to add `AC_PROG_LIBTOOL' src/ip/Makefile.am:4: to `configure.in' and run `aclocal' and `autoconf' again. automake failed Autotool bootstrapping failed. You will need to investigate and correct before you can develop on this source tree error: Bad exit status from /var/tmp/rpm-tmp.56670 (%build) and without doing ./bootstrap.sh autoreconf -fiv compile fails with: g++ -DHAVE_CONFIG_H -DDEFAULT_CONFIG_FILE=\/etc/squid/squid.conf\ -DDEFAULT_SQUID_DATA_DIR=\/usr/share/squid\ -DDEFAULT_SQUID_CONFIG_DIR=\/etc/squid\ -I.. -I../include -I../src -I../include -I../src -Wall -Wpointer-arith -Wwrite-strings -Wcomments -Werror -D_REENTRANT -m64 -fmessage-length=0 -D_FORTIFY_SOURCE=2 -O2 -Wall -fPIC -fno-strict-aliasing -MT LoadableModule.o -MD -MP -MF $depbase.Tpo -c -o LoadableModule.o LoadableModule.cc \ mv -f $depbase.Tpo $depbase.Po In file included from ../libltdl/ltdl.h:37, from LoadableModule.cc:10:
Re: perhaps OT: problem compiling 3.1.6 on SLES10-SP3
mån 2010-08-23 klockan 16:42 +0200 skrev Christian: maintaining the squid3 RPM on build.openuse.org. 3.1.4 was the last version I was able to compile without problems. for 3.1.5 I need to apply a small patch. (squid-bootstrap.patch) since 3.1.6 I not able to compile it for SLES10-SP3 Why are you autotool bootstrapping the source tree? The distributed tarball is already bootstrapped and ready for building. There is no need to run bootstrap.sh unless you are patching configure.in or Makefile.am. The LIBTOOL / AC_PROG_LIBTOOLS errors you are seeing on bootstrap is due to the source tree is now needing Libtool 2.x for bootstrapping. Libtool 2.x uses slightly different autoconf syntax compared to Libtool 1.x. In file included from ../libltdl/ltdl.h:37, from LoadableModule.cc:10: ../libltdl/libltdl/lt_error.h:35:31: error: libltdl/lt_system.h: No such file or directory I also saw this a couple of days ago when missing libtool-ltdl-devel package on one of my Fedora boxes. Have not yet looked into why this happens, it's supposed to work fine even without a system copy of ltdl. From your output it looks like the culpit is that -I $top/libltdl is missing from the compiler command. Try using the (new) configure flags for forcing internal libltdl to be used. Also try building without overriding CFLAGS CXXFLAGS in case configure adds it to the wrong variable.. Regards Henrik
Re: 1xx response forwarding and ignore_expect_100
On 08/21/2010 02:02 AM, Amos Jeffries wrote: The patch removes the ignore_expect_100 feature because we now forward 100 Continue messages. Is everybody OK with that removal? No. Bad naming maybe, but its primarily there to suppress 417 responses being generated in the negative case to broken clients. Even with working 1xx support internally we may still be required to suppress these (ie when forwarding to a known 1.0 peer). The original ignore_expect_100 code was quite intermingled with related HTTP violations, so I want to make sure I restore the necessary functionality. Do you want the following functionality? drop_expect_100 on|off Instructs Squid to ignore and remove received Expect: 100-continue request header(s), if any, before forwarding the request to the next hop. Without those headers, the server is likely to respond with a 100 (Continue) control message or a 417 (Expectation Failed) error(***). This option violates HTTP and may hurt clients that expect either a 100 (Continue) control message or a 417 (Expectation Failed) response to an Expect: 100-continue request. This option may help broken clients that cannot handle a 100 (Continue) control message or a 417 (Expectation Failed) response but still send an Expect: 100-continue request. As a side effect, it will prevent forwarding of 100 (Continue) control messages to HTTP/1.0 clients that send Expect: 100-continue headers. This option will not help broken HTTP/1.1 clients that cannot handle a 100 (Continue) control message when they did not send an Expect: 100-continue request. Thank you, Alex. (***) Patched Squid usually forwards but never generates such responses for 100-continue expectations. When we also add a server-side version check, Squid will start generating 417 (Expectation Failed) responses when it receives Expect:100-continue request for a known HTTP/1.0 server. This option will disable such 417 generation in Squid.
Re: [MERGE] Clean up htcp cache_peer options collapsing them into a single option with arguments
On 08/22/2010 07:17 AM, Amos Jeffries wrote: Henrik Nordstrom wrote: the list of HTCP mode options had grown a bit too large. Collapse them all into a single htcp= option taking a list of mode flags. Updated version of Henriks patch. (why did it not get committed last year when approved?) * parser bug fixed to handle a list of exactly one parameter without trailing comma (which the original would call bungled). * special parse case for htcp-oldsquid fully combined with new parser. * alters the cachemgr config dump to show the new syntax. Other than parse no operational changes. Fully backward-compatible and tested. This is not an objection to the patch, but if the various htcp-foo options set combine-able flags rather than a single htcp value, then please consider using htcp::flag namespace syntax instead of the htcp=flag assignment syntax. Thank you, Alex.
Re: [PATCH] Send chunked responses if body size is unknown.
On 08/22/2010 04:49 AM, Amos Jeffries wrote: Alex Rousskov wrote: Send chunked responses if body size is unknown. Apply HTTP chunked transfer encoding to the response body if all of the following conditions are met: * client claims HTTP version 1.1 or later support * response does not have a Content-Length header already * response does not use multipart/byteranges encoding * connection is persistent If we decide to send chunked reply, chunked_reply flag is set. Chunked encoding is done in ClientSocketContext::packChunk(). The last-chunk is sent only when clientReplyContext complete flag is set. This feature was requested to make Squid work with HTTP/1.1 clients that can handle chunked responses but cannot handle connection closures in the middle of a transaction sequence. The earlier version of the patch (for Squid v3.1) was tested in production. N.B. A bug in Squid may result in server-side code not treating premature server-side connection termination as an error. That bug results in Squid client-side sending a complete chunked response to the client instead of omitting the last-chunk to indicate a truncated response. Fixing that bug is outside this project scope (but we might have a patch for it somewhere, I need to check). +1. Though it's worth noting that the logic as given also excludes chunking in HTTP 2.0, 3.0, etc Indeed, I missed that bug. I have another patch somewhere that adds proper comparison operators to the HttpVersion class. Will use that instead of the hand-made comparison. Thank you, Alex.
Re: perhaps OT: problem compiling 3.1.6 on SLES10-SP3
On Mon, 23 Aug 2010 16:42:46 +0200, Christian ch...@computersalat.de wrote: Hi, maintaining the squid3 RPM on build.openuse.org. 3.1.4 was the last version I was able to compile without problems. for 3.1.5 I need to apply a small patch. (squid-bootstrap.patch) since 3.1.6 I not able to compile it for SLES10-SP3 while using ... snip spec %build export CFLAGS=$RPM_OPT_FLAGS -fPIE -fPIC -fno-strict-aliasing export CXXFLAGS=$RPM_OPT_FLAGS -fPIC -fno-strict-aliasing export LDFLAGS='-pie' ./bootstrap.sh autoreconf -fiv ./configure --prefix=/usr \ -snip I get: + ./bootstrap.sh automake (1.9) : automake autoconf (2.59) : autoconf libtool (1.5) : libtool libtool path : /usr/bin Bootstrapping compat/Makefile.am:12: Libtool library used but `LIBTOOL' is undefined compat/Makefile.am:12: compat/Makefile.am:12: The usual way to define `LIBTOOL' is to add `AC_PROG_LIBTOOL' compat/Makefile.am:12: to `configure.in' and run `aclocal' and `autoconf' again. src/Makefile.am:153: Libtool library used but `LIBTOOL' is undefined src/Makefile.am:153: src/Makefile.am:153: The usual way to define `LIBTOOL' is to add `AC_PROG_LIBTOOL' src/Makefile.am:153: to `configure.in' and run `aclocal' and `autoconf' again. src/acl/Makefile.am:4: Libtool library used but `LIBTOOL' is undefined src/acl/Makefile.am:4: src/acl/Makefile.am:4: The usual way to define `LIBTOOL' is to add `AC_PROG_LIBTOOL' src/acl/Makefile.am:4: to `configure.in' and run `aclocal' and `autoconf' again. src/adaptation/Makefile.am:15: Libtool library used but `LIBTOOL' is undefined src/adaptation/Makefile.am:15: src/adaptation/Makefile.am:15: The usual way to define `LIBTOOL' is to add `AC_PROG_LIBTOOL' src/adaptation/Makefile.am:15: to `configure.in' and run `aclocal' and `autoconf' again. src/adaptation/ecap/Makefile.am:4: Libtool library used but `LIBTOOL' is undefined src/adaptation/ecap/Makefile.am:4: src/adaptation/ecap/Makefile.am:4: The usual way to define `LIBTOOL' is to add `AC_PROG_LIBTOOL' src/adaptation/ecap/Makefile.am:4: to `configure.in' and run `aclocal' and `autoconf' again. src/adaptation/icap/Makefile.am:4: Libtool library used but `LIBTOOL' is undefined src/adaptation/icap/Makefile.am:4: src/adaptation/icap/Makefile.am:4: The usual way to define `LIBTOOL' is to add `AC_PROG_LIBTOOL' src/adaptation/icap/Makefile.am:4: to `configure.in' and run `aclocal' and `autoconf' again. src/auth/Makefile.am:7: Libtool library used but `LIBTOOL' is undefined src/auth/Makefile.am:7: src/auth/Makefile.am:7: The usual way to define `LIBTOOL' is to add `AC_PROG_LIBTOOL' src/auth/Makefile.am:7: to `configure.in' and run `aclocal' and `autoconf' again. src/base/Makefile.am:5: Libtool library used but `LIBTOOL' is undefined src/base/Makefile.am:5: src/base/Makefile.am:5: The usual way to define `LIBTOOL' is to add `AC_PROG_LIBTOOL' src/base/Makefile.am:5: to `configure.in' and run `aclocal' and `autoconf' again. src/esi/Makefile.am:4: Libtool library used but `LIBTOOL' is undefined src/esi/Makefile.am:4: src/esi/Makefile.am:4: The usual way to define `LIBTOOL' is to add `AC_PROG_LIBTOOL' src/esi/Makefile.am:4: to `configure.in' and run `aclocal' and `autoconf' again. src/fs/Makefile.am:3: Libtool library used but `LIBTOOL' is undefined src/fs/Makefile.am:3: src/fs/Makefile.am:3: The usual way to define `LIBTOOL' is to add `AC_PROG_LIBTOOL' src/fs/Makefile.am:3: to `configure.in' and run `aclocal' and `autoconf' again. src/icmp/Makefile.am:25: Libtool library used but `LIBTOOL' is undefined src/icmp/Makefile.am:25: src/icmp/Makefile.am:25: The usual way to define `LIBTOOL' is to add `AC_PROG_LIBTOOL' src/icmp/Makefile.am:25: to `configure.in' and run `aclocal' and `autoconf' again. src/ident/Makefile.am:4: Libtool library used but `LIBTOOL' is undefined src/ident/Makefile.am:4: src/ident/Makefile.am:4: The usual way to define `LIBTOOL' is to add `AC_PROG_LIBTOOL' src/ident/Makefile.am:4: to `configure.in' and run `aclocal' and `autoconf' again. src/ip/Makefile.am:4: Libtool library used but `LIBTOOL' is undefined src/ip/Makefile.am:4: src/ip/Makefile.am:4: The usual way to define `LIBTOOL' is to add `AC_PROG_LIBTOOL' src/ip/Makefile.am:4: to `configure.in' and run `aclocal' and `autoconf' again. automake failed Autotool bootstrapping failed. You will need to investigate and correct before you can develop on this source tree error: Bad exit status from /var/tmp/rpm-tmp.56670 (%build) and without doing ./bootstrap.sh autoreconf -fiv compile fails with: g++ -DHAVE_CONFIG_H -DDEFAULT_CONFIG_FILE=\/etc/squid/squid.conf\ -DDEFAULT_SQUID_DATA_DIR=\/usr/share/squid\ -DDEFAULT_SQUID_CONFIG_DIR=\/etc/squid\ -I.. -I../include -I../src -I../include -I../src -Wall -Wpointer-arith -Wwrite-strings -Wcomments -Werror -D_REENTRANT -m64 -fmessage-length=0 -D_FORTIFY_SOURCE=2 -O2 -Wall -fPIC -fno-strict-aliasing -MT LoadableModule.o -MD
Re: [PATCH] Bug #2583 fix: pure virtual method called
On 08/22/2010 01:08 AM, Amos Jeffries wrote: Alex Rousskov wrote: Bug #2583 fix: pure virtual method called When a cbdata-protected class holds its own cbdata and has virtual toCbdata(), there is a catch22 problem: we need cbdata to know whether the pointer to the class object is valid, and we need to dereference that pointer to get cbdata. Added CbcPointer class to hold both a pointer to a potentially freed class object and the cbdata pointer protecting that object. Keeping the cbdata pointer allows us to test whether the object is still there without dereferencing the object pointer. Use the CbcPointer class to hold safe pointers to AsyncJobs. This prevents pure virtual method called failures because we no longer dereference freed job pointers. Removed Initiator parameter from many initiatee constructors. The Adaptation::Initiator::initiateAdaptation method now sets the initiator of the job. This makes the constructor profile simpler and removes the need to propagate Initiator changes through all the [nested] constructors. Renamed AsyncJob::AsyncStart() to AsyncJob::Start(). I had to change the callers code anyway and it was a good opportunity to remove the redundant Async. Special thanks to Stefan Fritsch for updating and testing an earlier version of this patch. --- P.S. The underlying changes have been tested in production but I had to polish them before submitting to trunk. Some advanced C++ concepts might not compile on old/broken compilers. We will try to remove/change them if needed. P.P.S. This change is required for at least one more bug fix and for the the 1xx handling patch. One problem: src/base/CbcPointer.h: * #include TextException.h needs to be base/TextException.h. NP: this should be failing on build since -I. is undefined in src/. Fixed. I do not know why the builds (and make check) did not fail. The rest is just more polish Several of the files with added #include entries: * For clarity as they grow its useful to keep the #include statements alphabetical. The old code remains messy, but no need to mess the nice clean new code. :) I have moved new #include entries where they were out of the alphabetical order. I was not aware of this documented requirement, sorry. * If this is for order-dependent includes that is a violation of the testHeaders dependency guarantee in all src/* .h code. Ditto for *_SOURCES list in src/base/Makefile.am. Moved. src/CommCalls.h: * useless whitespace addition. Fixed, sorry. Other than that +1. Committed to trunk as r10779. Thank you, Alex.
Re: auth_param ntlm keep_alive interaction with new http/1.1 keepalive behaviour
Amos, As I understand it, keep-alive off is for this exchange: GET 407 NTLM PC:Close * (reconnect) GET NTLM hash 407 NTLM hash GET NTLM authdetails But the situation I am experiencing is after a rejected authentication attempt. I.e. here: GET 407 NTLM PC:Close (reconnect) GET NTLM hash 407 NTLM hash GET NTLM authdetails 407 NTLM ** (reconnect here is required to avoid multiple auth prompts) GET NTLM hash 407 NTLM hash GET NTLM authdetails I have had this problem reported with both MSIE and Firefox. Rigerous testing with tcpdumps has only been performed with firefox. -- Regards, Stephen Thorne Development Engineer Netbox Blue
Re: [PATCH] Optimize HttpVersion comparison
On Tue, Aug 24, 2010 at 1:52 AM, Alex Rousskov rouss...@measurement-factory.com wrote: It is easy to get HTTP version comparison wrong. I have added a few comparison operators. To be efficient, they need to be inlined by the compiler so that the following expression does not have to cause HttpVersion(1,0) creation and destruction: if (request-http_ver = HttpVersion(1, 0)) I tried to simplify the constructors and the quality comparison operator to increase our chances that they will be inlined. Unfortunately, I ran into a GCC feature which probably explains why we have not written the HttpVersion constructor correctly before. I added a workaround. Should those #undef lines be moved to some compatibility file? If yes, which one? Can't we just name our data fields Major and Minor? Also, would adding the inline keyword hint the compiler about our wishes? I guess it wouldn't hurt (it would also probably not help either, but still..) Apart from that, +1. -- /kinkie
Re: [MERGE] Clean up htcp cache_peer options collapsing them into a single option with arguments
On Mon, 23 Aug 2010 15:28:23 -0600, Alex Rousskov rouss...@measurement-factory.com wrote: On 08/22/2010 07:17 AM, Amos Jeffries wrote: Henrik Nordstrom wrote: the list of HTCP mode options had grown a bit too large. Collapse them all into a single htcp= option taking a list of mode flags. Updated version of Henriks patch. (why did it not get committed last year when approved?) * parser bug fixed to handle a list of exactly one parameter without trailing comma (which the original would call bungled). * special parse case for htcp-oldsquid fully combined with new parser. * alters the cachemgr config dump to show the new syntax. Other than parse no operational changes. Fully backward-compatible and tested. This is not an objection to the patch, but if the various htcp-foo options set combine-able flags rather than a single htcp value, then please consider using htcp::flag namespace syntax instead of the htcp=flag assignment syntax. Some are combinable some are mutually exclusive. They all enable HTCP communication plus setting additional behaviour modifiers. The basic config is just an htcp. The point of this change was to avoid a series of individual flag entries on the cache_peer line. The possibility of doing multiple behaviour 'assignments' is retained for backward-compatibility but is not exactly desirable and undocumented to discourage. ie the syntax meaning of htcp=oldsquid,no-clr is: HTCP on, with oldsquid behaviour but no CLR requests. Amos
Build failed in Hudson: 3.HEAD-i386-Debian-sid #364
See http://build.squid-cache.org/job/3.HEAD-i386-Debian-sid/364/changes Changes: [Automatic source maintenance squid...@squid-cache.org] SourceFormat Enforcement [Alex Rousskov rouss...@measurement-factory.com] Send chunked responses if body size is unknown. Apply HTTP chunked transfer encoding to the response body sent to client if all of the following conditions are met: * client claims HTTP version 1.1 or later support * response does not have a Content-Length header already * response does not use multipart/byteranges encoding * connection is persistent If we decide to send chunked reply, chunked_reply flag is set. Chunked encoding is done in ClientSocketContext::packChunk(). The last-chunk is sent only when clientReplyContext complete flag is set. This change helps keep client-side connections persistent. [Alex Rousskov rouss...@measurement-factory.com] Added more comparison operators to HttpVersion. [Alex Rousskov rouss...@measurement-factory.com] Bug #2583 fix: pure virtual method called When a cbdata-protected class holds its own cbdata and has virtual toCbdata(), there is a catch22 problem: we need cbdata to know whether the pointer to the class object is valid, and we need to dereference that pointer to get cbdata. Added CbcPointer class to hold both a pointer to a potentially freed class object and the cbdata pointer protecting that object. Keeping the cbdata pointer allows us to test whether the object is still there without dereferencing the object pointer. Use the CbcPointer class to hold safe pointers to AsyncJobs. This prevents pure virtual method called failures because we no longer dereference freed job pointers. Removed Initiator parameter from many initiatee constructors. The Adaptation::Initiator::initiateAdaptation method now sets the initiator of the job. This makes the constructor profile simpler and removes the need to propagate Initiator changes through all the [nested] constructors. Renamed AsyncJob::AsyncStart() to AsyncJob::Start(). I had to change the callers code anyway and it was a good opportunity to remove the redundant Async. Special thanks to Stefan Fritsch for updating and testing an earlier version of this patch. [Francesco Chemolli kin...@squid-cache.org] Compatibility fixes for Solaris/gcc -- [...truncated 3023 lines...] gcc -DSQUID_SNMP=1 -I../.. -I../include -I../../include -Wall -Wpointer-arith -Wwrite-strings -Wmissing-prototypes -Wmissing-declarations -Wcomments -Werror -pipe -D_REENTRANT -MT parse.o -MD -MP -MF .deps/parse.Tpo -c -o parse.o ../../snmplib/parse.c mv -f .deps/parse.Tpo .deps/parse.Po gcc -DSQUID_SNMP=1 -I../.. -I../include -I../../include -Wall -Wpointer-arith -Wwrite-strings -Wmissing-prototypes -Wmissing-declarations -Wcomments -Werror -pipe -D_REENTRANT -MT snmp_vars.o -MD -MP -MF .deps/snmp_vars.Tpo -c -o snmp_vars.o ../../snmplib/snmp_vars.c mv -f .deps/snmp_vars.Tpo .deps/snmp_vars.Po gcc -DSQUID_SNMP=1 -I../.. -I../include -I../../include -Wall -Wpointer-arith -Wwrite-strings -Wmissing-prototypes -Wmissing-declarations -Wcomments -Werror -pipe -D_REENTRANT -MT coexistance.o -MD -MP -MF .deps/coexistance.Tpo -c -o coexistance.o ../../snmplib/coexistance.c mv -f .deps/coexistance.Tpo .deps/coexistance.Po gcc -DSQUID_SNMP=1 -I../.. -I../include -I../../include -Wall -Wpointer-arith -Wwrite-strings -Wmissing-prototypes -Wmissing-declarations -Wcomments -Werror -pipe -D_REENTRANT -MT snmp_api.o -MD -MP -MF .deps/snmp_api.Tpo -c -o snmp_api.o ../../snmplib/snmp_api.c mv -f .deps/snmp_api.Tpo .deps/snmp_api.Po gcc -DSQUID_SNMP=1 -I../.. -I../include -I../../include -Wall -Wpointer-arith -Wwrite-strings -Wmissing-prototypes -Wmissing-declarations -Wcomments -Werror -pipe -D_REENTRANT -MT snmp_error.o -MD -MP -MF .deps/snmp_error.Tpo -c -o snmp_error.o ../../snmplib/snmp_error.c mv -f .deps/snmp_error.Tpo .deps/snmp_error.Po gcc -DSQUID_SNMP=1 -I../.. -I../include -I../../include -Wall -Wpointer-arith -Wwrite-strings -Wmissing-prototypes -Wmissing-declarations -Wcomments -Werror -pipe -D_REENTRANT -MT mib.o -MD -MP -MF .deps/mib.Tpo -c -o mib.o ../../snmplib/mib.c mv -f .deps/mib.Tpo .deps/mib.Po gcc -DSQUID_SNMP=1 -I../.. -I../include -I../../include -Wall -Wpointer-arith -Wwrite-strings -Wmissing-prototypes -Wmissing-declarations -Wcomments -Werror -pipe -D_REENTRANT -MT snmp_api_error.o -MD -MP -MF .deps/snmp_api_error.Tpo -c -o snmp_api_error.o ../../snmplib/snmp_api_error.c mv -f .deps/snmp_api_error.Tpo .deps/snmp_api_error.Po gcc -DSQUID_SNMP=1 -I../.. -I../include -I../../include -Wall -Wpointer-arith -Wwrite-strings -Wmissing-prototypes -Wmissing-declarations -Wcomments -Werror -pipe -D_REENTRANT -MT snmp_msg.o -MD -MP -MF .deps/snmp_msg.Tpo -c -o snmp_msg.o ../../snmplib/snmp_msg.c mv -f .deps/snmp_msg.Tpo .deps/snmp_msg.Po gcc -DSQUID_SNMP=1 -I../.. -I../include -I../../include -Wall -Wpointer-arith -Wwrite-strings
Re: [PATCH] Optimize HttpVersion comparison
On 08/23/2010 06:22 PM, Kinkie wrote: On Tue, Aug 24, 2010 at 1:52 AM, Alex Rousskov rouss...@measurement-factory.com wrote: It is easy to get HTTP version comparison wrong. I have added a few comparison operators. To be efficient, they need to be inlined by the compiler so that the following expression does not have to cause HttpVersion(1,0) creation and destruction: if (request-http_ver= HttpVersion(1, 0)) I tried to simplify the constructors and the quality comparison operator to increase our chances that they will be inlined. Unfortunately, I ran into a GCC feature which probably explains why we have not written the HttpVersion constructor correctly before. I added a workaround. Should those #undef lines be moved to some compatibility file? If yes, which one? Can't we just name our data fields Major and Minor? Those specific names would violate member naming policy, but we can find other names, of course (e.g., majr and minr). It would require changing caller code which I wanted to avoid though. Also, would adding the inline keyword hint the compiler about our wishes? I guess it wouldn't hurt (it would also probably not help either, but still..) It might, but only if the method definition is separated from the declaration. In our case, all methods are defined and declared simultaneously. I have not checked whether that is enough for GCC to inline everything though. Apart from that, +1. I am not going to commit this optimization until there is consensus on how to handle the major/minor naming conflict with GCC. Thank you, Alex.
Re: [MERGE] Clean up htcp cache_peer options collapsing them into a single option with arguments
On 08/23/2010 06:36 PM, Amos Jeffries wrote: On Mon, 23 Aug 2010 15:28:23 -0600, Alex Rousskov rouss...@measurement-factory.com wrote: On 08/22/2010 07:17 AM, Amos Jeffries wrote: Henrik Nordstrom wrote: the list of HTCP mode options had grown a bit too large. Collapse them all into a single htcp= option taking a list of mode flags. Updated version of Henriks patch. (why did it not get committed last year when approved?) * parser bug fixed to handle a list of exactly one parameter without trailing comma (which the original would call bungled). * special parse case for htcp-oldsquid fully combined with new parser. * alters the cachemgr config dump to show the new syntax. Other than parse no operational changes. Fully backward-compatible and tested. This is not an objection to the patch, but if the various htcp-foo options set combine-able flags rather than a single htcp value, then please consider using htcp::flag namespace syntax instead of the htcp=flag assignment syntax. Some are combinable some are mutually exclusive. They all enable HTCP communication plus setting additional behaviour modifiers. The basic config is just an htcp. The point of this change was to avoid a series of individual flag entries on the cache_peer line. The possibility of doing multiple behaviour 'assignments' is retained for backward-compatibility but is not exactly desirable and undocumented to discourage. ie the syntax meaning of htcp=oldsquid,no-clr is: HTCP on, with oldsquid behaviour but no CLR requests. Sounds good. Since values are flags that we do not really assign, you could still do htcp::oldsquid,no-clr, but it is not clear to me whether that would be really better than assignment. Thank you, Alex.
Build failed in Hudson: 3.HEAD-i386-Debian-sid #365
See http://build.squid-cache.org/job/3.HEAD-i386-Debian-sid/365/changes Changes: [Automatic source maintenance squid...@squid-cache.org] SourceFormat Enforcement -- [...truncated 2975 lines...] gcc -DSQUID_SNMP=1 -I../.. -I../include -I../../include -Wall -Wpointer-arith -Wwrite-strings -Wmissing-prototypes -Wmissing-declarations -Wcomments -Werror -pipe -D_REENTRANT -MT parse.o -MD -MP -MF .deps/parse.Tpo -c -o parse.o ../../snmplib/parse.c mv -f .deps/parse.Tpo .deps/parse.Po gcc -DSQUID_SNMP=1 -I../.. -I../include -I../../include -Wall -Wpointer-arith -Wwrite-strings -Wmissing-prototypes -Wmissing-declarations -Wcomments -Werror -pipe -D_REENTRANT -MT snmp_vars.o -MD -MP -MF .deps/snmp_vars.Tpo -c -o snmp_vars.o ../../snmplib/snmp_vars.c mv -f .deps/snmp_vars.Tpo .deps/snmp_vars.Po gcc -DSQUID_SNMP=1 -I../.. -I../include -I../../include -Wall -Wpointer-arith -Wwrite-strings -Wmissing-prototypes -Wmissing-declarations -Wcomments -Werror -pipe -D_REENTRANT -MT coexistance.o -MD -MP -MF .deps/coexistance.Tpo -c -o coexistance.o ../../snmplib/coexistance.c mv -f .deps/coexistance.Tpo .deps/coexistance.Po gcc -DSQUID_SNMP=1 -I../.. -I../include -I../../include -Wall -Wpointer-arith -Wwrite-strings -Wmissing-prototypes -Wmissing-declarations -Wcomments -Werror -pipe -D_REENTRANT -MT snmp_api.o -MD -MP -MF .deps/snmp_api.Tpo -c -o snmp_api.o ../../snmplib/snmp_api.c mv -f .deps/snmp_api.Tpo .deps/snmp_api.Po gcc -DSQUID_SNMP=1 -I../.. -I../include -I../../include -Wall -Wpointer-arith -Wwrite-strings -Wmissing-prototypes -Wmissing-declarations -Wcomments -Werror -pipe -D_REENTRANT -MT snmp_error.o -MD -MP -MF .deps/snmp_error.Tpo -c -o snmp_error.o ../../snmplib/snmp_error.c mv -f .deps/snmp_error.Tpo .deps/snmp_error.Po gcc -DSQUID_SNMP=1 -I../.. -I../include -I../../include -Wall -Wpointer-arith -Wwrite-strings -Wmissing-prototypes -Wmissing-declarations -Wcomments -Werror -pipe -D_REENTRANT -MT mib.o -MD -MP -MF .deps/mib.Tpo -c -o mib.o ../../snmplib/mib.c mv -f .deps/mib.Tpo .deps/mib.Po gcc -DSQUID_SNMP=1 -I../.. -I../include -I../../include -Wall -Wpointer-arith -Wwrite-strings -Wmissing-prototypes -Wmissing-declarations -Wcomments -Werror -pipe -D_REENTRANT -MT snmp_api_error.o -MD -MP -MF .deps/snmp_api_error.Tpo -c -o snmp_api_error.o ../../snmplib/snmp_api_error.c mv -f .deps/snmp_api_error.Tpo .deps/snmp_api_error.Po gcc -DSQUID_SNMP=1 -I../.. -I../include -I../../include -Wall -Wpointer-arith -Wwrite-strings -Wmissing-prototypes -Wmissing-declarations -Wcomments -Werror -pipe -D_REENTRANT -MT snmp_msg.o -MD -MP -MF .deps/snmp_msg.Tpo -c -o snmp_msg.o ../../snmplib/snmp_msg.c mv -f .deps/snmp_msg.Tpo .deps/snmp_msg.Po gcc -DSQUID_SNMP=1 -I../.. -I../include -I../../include -Wall -Wpointer-arith -Wwrite-strings -Wmissing-prototypes -Wmissing-declarations -Wcomments -Werror -pipe -D_REENTRANT -MT snmp_pdu.o -MD -MP -MF .deps/snmp_pdu.Tpo -c -o snmp_pdu.o ../../snmplib/snmp_pdu.c mv -f .deps/snmp_pdu.Tpo .deps/snmp_pdu.Po gcc -DSQUID_SNMP=1 -I../.. -I../include -I../../include -Wall -Wpointer-arith -Wwrite-strings -Wmissing-prototypes -Wmissing-declarations -Wcomments -Werror -pipe -D_REENTRANT -MT snmplib_debug.o -MD -MP -MF .deps/snmplib_debug.Tpo -c -o snmplib_debug.o ../../snmplib/snmplib_debug.c mv -f .deps/snmplib_debug.Tpo .deps/snmplib_debug.Po rm -f libsnmp.a /usr/bin/ar cru libsnmp.a asn1.o parse.o snmp_vars.o coexistance.o snmp_api.o snmp_error.o mib.o snmp_api_error.o snmp_msg.o snmp_pdu.o snmplib_debug.o ranlib libsnmp.a make[2]: Leaving directory `http://build.squid-cache.org/job/3.HEAD-i386-Debian-sid/ws/btlayer-00-default/squid-3.HEAD-BZR/_build/snmplib' Making all in libltdl make[2]: Entering directory `http://build.squid-cache.org/job/3.HEAD-i386-Debian-sid/ws/btlayer-00-default/squid-3.HEAD-BZR/_build/libltdl' make all-am make[3]: Entering directory `http://build.squid-cache.org/job/3.HEAD-i386-Debian-sid/ws/btlayer-00-default/squid-3.HEAD-BZR/_build/libltdl' /bin/sh ./libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I../../libltdl -DLT_CONFIG_H='config.h' -DLTDL -I. -I../../libltdl -Ilibltdl -I../../libltdl/libltdl -I../../libltdl/libltdl -g -O2 -MT dlopen.lo -MD -MP -MF .deps/dlopen.Tpo -c -o dlopen.lo `test -f 'loaders/dlopen.c' || echo '../../libltdl/'`loaders/dlopen.c libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../../libltdl -DLT_CONFIG_H=config.h -DLTDL -I. -I../../libltdl -Ilibltdl -I../../libltdl/libltdl -I../../libltdl/libltdl -g -O2 -MT dlopen.lo -MD -MP -MF .deps/dlopen.Tpo -c ../../libltdl/loaders/dlopen.c -fPIC -DPIC -o .libs/dlopen.o libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../../libltdl -DLT_CONFIG_H=config.h -DLTDL -I. -I../../libltdl -Ilibltdl -I../../libltdl/libltdl -I../../libltdl/libltdl -g -O2 -MT dlopen.lo -MD -MP -MF .deps/dlopen.Tpo -c ../../libltdl/loaders/dlopen.c -o dlopen.o /dev/null 21 mv -f
