On 26/01/2016 11:22 p.m., L.P.H. van Belle wrote: > Hai, > > > > Ok, good is its working now, i was pulling my hair out for you ;-) > > > > This : sed -i 's/g++ (>= 4:5.2)/g++/g' libecap-1.0.1/debian/control > > Is not any problem, because squid is reconfigured and recompiled with G++ 4.9. > > > > If you want a more secure set, you can change this to : > > sed -i 's/g++ (>= 4:5.2)/g++ (>= 4:4.9)/g' libecap-1.0.1/debian/control > > This way its “locked” to minimal g++ 4.9. > > > > And i cant think of any other restriction. > > Maybe Amos knows, but i dont know that. It is to do with the Debian GCC 5 transition. If a binary and library are built with different GCC 4.9 and GCC 5 versions there can be some very strange behaviours from memory corruption on the stack. That condition is there to ensure the new ecap library is only ever built with GCC 5, and thus the Squid which depend on it need to be as well. If you don't need eCAP I recommend removing it entirely from your backport build. That will make future upgrades easier. If you do need eCAP then you should backport the libecap package to use a different package name than the one used by Debian and adjust your Squid dependency to that new name. The above stack issues could appear if squid auto-upgrades later and the libecap does not. Amos _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
