On 23/08/11 09:05, gewehre@xxxxxxx wrote:
On Mac OS X 10.4.11, squid-3.1.14 from July 4 doesn't have this problem, but the last nightly release (squid-3.1.14-20110804) complains about "Bungled Default Configuration line 8: miss_access allow all" with the exact same config. Line 8 in my squid.conf is "acl to_localhost dst 127.0.0.0/8 0.0.0.0/32 ::1".
Um, I suspect you got the nightly build of 3.2 instead of 3.1. All the warnings etc match up with 3.2 code better than 3.1
Strange Bungled warning. "Default Configuration" is the hard-coded default values loaded before any files. Can you check if src/cf_parser.cci in the build directory contains a default definition for the "all" ACL?
And please make sure this is still a problem when you do a fresh clean set of sources.
A second issue is "--enable-ssl" always has to be left out of my ./configure, in order for any squid-3.1.14 to compile. Had no such issue with much older 3.1.x releases, as far as I can recall. I don't use squid as a reverse-proxy, so it's no big loss.
Yes, we have an open bug about that. Still looking for the source of the problem and a properly working solution.
With recent 3.2 nightlies, I encounter another issue that I can get around by explicitly specifying "--disable-auth-negotiate": ... cc1plus: warnings being treated as errors negotiate_wrapper.cc: In function 'int main(int, char* const*)': negotiate_wrapper.cc:113: warning: 'length' may be used uninitialized in this function make[3]: *** [negotiate_wrapper.o] Error 1 make[2]: *** [all-recursive] Error 1 make[1]: *** [all-recursive] Error 1 make: *** [all-recursive] Error 1
Thank you. Appears to be a false positive by the compiler. But looking into it found some weird code and an unused variable. Removing that fixes some potential confusion for the compiler.
If you want to try it, the patch will be here once the mirrors pick it up: http://www.squid-cache.org/Versions/v3/3.HEAD/changesets/squid-3-11668.patch
I'm then confronted with the old nemesis: ... cc1plus: warnings being treated as errors Address.cc: In member function 'bool Ip::Address::IsSlaac() const': Address.cc:279: warning: comparison is always false due to limited range of data type Address.cc:280: warning: comparison is always false due to limited range of data type Some googling seems to suggest this is rather common with certain UNIX source codes and OS X (x86 little endian hardware).
Strange. The comparison is constant and performed in network-order octet bitmaps. There should be no range conversions involved. Erasing possible endian problems is precisely why the htons() was used.
Could you please test with replacing the "htons" on those lines with "static_cast<uint8_t>".
PS. What compiler is reporting these? Amos -- Please be using Current Stable Squid 2.7.STABLE9 or 3.1.14 Beta testers wanted for 3.2.0.10
