C++11 with the requirement for gcc-4.8 would really be a show-stopper for most existing systems... For example RHEL6 still ships with gcc-4.4.7, so a switch there would result in cutting off Centos/RHEL6 as well. Even the Debian I have running on my Raspberry Pi only comes with gcc-4.7.2 as the latest installable option. Only RHEL7beta ships with 4.8 as far as I can tell. And for that to go mainstream one will need to wait at least another year after the official release (which is probably in Q3-2014). So that would definitely reduce possible audience for any squid 3.5 release that makes use of C++11. And having people compile gcc and the required dependencies themselves first is another support-nightmare... I guess People would more likely stay with the older squid version (even if they are buggy) than spending that amount of time and Hassle just to get all the dependencies compiled or even think of upgrading to a new OS version... Out of curiosity: which features of c++11 do you want to use to make gcc 4.8 an absolute requirement for the next major release? Just my 2 cents Martin -----Original Message----- From: Amos Jeffries [mailto:squid3@xxxxxxxxxxxxx] Sent: Montag, 05. Mai 2014 17:14 To: squid-users@xxxxxxxxxxxxxxx Subject: Re: Squid 3.4.5 is available On 6/05/2014 2:09 a.m., Martin Sperl wrote: > Hi Amos! > > Does this mean that squid 3.4.4 is no longer supported on > RedHat Enterprise/Centos 5 (ships with autoconf 2.59)? > RHEL 6 comes with exactly 2.63, so any future update will > mean that RHEL6 may also become unsupported as well. That OS version has been best-effort for some months now. We aim to test on the latest stable, previous stable, and if possible and upcoming/rolling release when we can. For CentOS we test on CentOS 6 and 6.5. > > Just tracking upstream "authconf" is bound to produce similar > pains that I have already experienced with RRDTool on RH3, > RH4, RH5 systems. Yes. We are not tracking "autoconf" upstream itself, but the packaging is now done on a Debian based machine which does have more frequent toolchain updates than our previous FreeBSD 5 machine. On the other hand the C++11 usage is more likely to have an blocking impact on those old RHEL systems. Do they have GCC 4.8 available? at least in unofficial packages. Or can they by Dec? > > I assume that the tar-balls will still get delivered with the > ./configure files, so the "direct" need of autoconf versions > may be less important for lots of people just compiling. > But it still may break at some point resulting in unexpected > behavior - probably during a really important bug-fix > release... Yes, the tar-balls will still be delivered as before. Murphys law dictates that such breakage will occur whatever we do ... > > So I wonder if it is really a wise move to potentially cut off > people from security patches because they can no longer > compile squid on the system they want to use it on just > due to the build-tool dependencies. > > Is there maybe a plan not to change build-tool versions > within a minor version (3.4, 3.5, ...) to somewhat avoid > such issues? ... ironically it is security issues which have prompted this change. Our FreeBSD 5 machine was getting too outdated and un-patchable. The biggest toolchain pains over the last few years have been due to our old toolchain versions having incompatibilities compiling on the more up to date OS distributions. Not least of which is 2-digit version numbers and detecting newer available tools. The aim is to make big changes in the toolchains only with beta release testing. For this change it was done in 3.4.4.1 and 3.4.4.2 beta packages last month. Overall we have to face the same version compatibility issues in the toolchain regardless of which versions we distribute with. At least there is a slightly better chance of backward compatility being embeded in the scripts from updated bundled versions than forward-compatibility being embeded by the old. The toolchain upstream have been making some strong efforts in that direction recent years which adds benefit to this change. For those with very large problems the bootstrap.sh script is available in the repository which can regenerate the build scripts against many older version(s) of the toolchain as a last resort. HTH Amos This message and the information contained herein is proprietary and confidential and subject to the Amdocs policy statement, you may review at http://www.amdocs.com/email_disclaimer.asp
