On 6/05/2014 6:52 p.m., Martin Sperl wrote: > 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). > This is what we have been waiting for. These last popular distros to have some form of formal release announced that will include the necessary compilers. Their next major series start going public early 2015 by all accounts. Plan is to have C++11 for the Squid series following that late in 2015. > So that would definitely reduce possible audience for any squid > 3.5 release that makes use of C++11. > I know, note the version particular is omitted from the announcement so far. It is probable the version to go stable with this change will actually be 3.6. People will just see 3.HEAD builds as early as the end of the year needing the newer compiler, thus the early announcement. > 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? Atomics for better/simpler SMP and to begin native threading of some components. Lambdas for better hashing, indexing algorithms ACLs etc. Move constructors for better performance across the board. Auto type deduction for simpler APIs on most of the complex template APIs. Each time we go diving into documentation for features we find something else. Some of these like move constructors are already being relied on for performance gains in 3.5 via the increased STL usage. There are other features which we have managed to write custom replacements for 3.3+ (ie nullptr and some of the atomics). However we expect to see small but measurable difference in speed between Squid binaries depending on the compiler version used to build it. > > Just my 2 cents > > Martin > Thank you. Cheers Amos > -----Original Message----- > From: Amos Jeffries > > 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 >
