Re: [squid-users] Build issues with squid 3.1 and 3.2

On 23/08/11 09:05, gewehre_at_gmx.net 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