On 01/27/2014 03:23 AM, Stefano Cordibella wrote: > So now is the compile steps that fails, I have the following error: > In file included from PortCfg.cc:2:0: > ../../src/anyp/PortCfg.h:14:7: error: 'AnyP::PortCfg' declared with > greater visibility than the type of its field > 'AnyP::PortCfg::staticSslContext' [-Werror=attributes] > I suppose that this issue came from my SSL modification in configure (I > am using openssl 1.0.1e)... > Have you any idea on how to fix it? I have not seen such a warning before, but perhaps Squid just cannot find openssl/ssl.h or a similar header file? Check ./configure log for SSL-related header checks. Most or even all of the following HAVE_OPPENSSL* constants should be defined after you run ./configure: fgrep HAVE_OPENSSL ../include/autoconf.h Also, consider posting a patch or unified diff containing your ./configure-related *.m4 changes in addition to their English description you have already provided. And you may want to post ./configure output so that we can see the _effects) of those changes. HTH, Alex. > On 01/24/2014 11:10 PM, Alex Rousskov wrote: >> On 01/24/2014 01:04 AM, Stefano Cordibella wrote: >>> Thank you Amos for your answer! >>> >>> I am using these cross compiler flags (that seems right for me): >>> --build=x86_64-linux >>> --host=i586-oe-linux >>> --target=i586-oe-linux >>> >>> Configure exit with this error: >>> checking for GNU atomic operations support... configure: error: in >>> `/<real_long_path>/tmp-eglibc/work/x86-oe-linux/squid/3.3.11-r19.9/squid-3.3.11': >>> >>> >>> configure: error: cannot run test program while cross compiling >> Please see bug 3975. It has a generally wrong patch that may work OK for >> your case and a discussion leading to the right solution (but no patch): >> >> http://bugs.squid-cache.org/show_bug.cgi?id=3975 >> >> If you can implement that right solution, test, and post a patch that >> would be great! >> >> >> Cheers, >> >> Alex. >> >> >>> Here are some details of my build machine: >>> It was created by Squid Web Proxy configure 3.3.11, which was >>> generated by GNU Autoconf 2.69. >>> >>> automake (GNU automake) 1.12.6 >>> >>> uname -m = x86_64 >>> uname -r = 2.6.32-5-xen-amd64 >>> uname -s = Linux >>> uname -v = #1 SMP Fri May 10 11:48:05 UTC 2013 >>> >>> What can be the issue? >>> >>> Cheers, >>> Stefano. >>> >>> On 01/23/2014 06:39 PM, squid-users-digest-help@xxxxxxxxxxxxxxx wrote: >>>> On 23/01/2014 10:39 p.m., Stefano Cordibella wrote: >>>>>> Hi list, >>>>>> I am trying to compile squid 3.3.11 in our openembedded >>>>> environment, >>>>>> but the configure step fails due to a cross compile check. >>>>>> In version 3.1.23 there wasn't those checks and the build goes >>>>>> well... >>>>>> >>>>>> So my questions are: >>>>>> 1) why from version 3.2 these checks are included in configure? >>>> The change in behaviour is from newer autoconf being used to generate >>>> the code tarballs. One of the reasons for that was to get better/easier >>>> cross-compiling support. >>>> >>>> >>>>>> 2) are there any way to cross compile 3.3 (or 3.4)? >>>> You should only** have to specify the ./configure options to tell it >>>> which OS the compile is happening on (--build=X) and which OS type will >>>> run the binary (--host=Y). >>>> >>>> What exactly is the failure you are encountering? >>>> >>>> >>>> ** besides having the appropriate *-dev library versions installed for >>>> cross-compiling against and tools that can cross-compile. >>>> >>>> >>>>>> 3) I read in the FAQ that from version 3.2 C++11 compilers is >>>>>> required, >>>>>> I am using gcc 4.7.2, is it a supported compiler? >>>> Not required. "Preferred" is the word for it. We have code to make use >>>> of some C++11 only when available. Mostly we are taking advantage of >>>> the >>>> increased compiler code checking in our build farm to remove bugs >>>> before >>>> anyone notices them:-) >>>> >>>> The switch to mandatory C++11 support for general builds is still being >>>> discussed on squid-dev and IRC as to when the timing would offer least >>>> pain for everyonea and how long we can procrastinate on it. It might >>>> happen around Squid-3.6. >>>> >>>> Any GCC 4.0+ (excluding 4.5 with broken stdlib definitions of >>>> auto_ptr/unique_ptr) should work fine for Squid-3.2 and later. The >>>> later >>>> versions are better though with more general C++11 support benfits than >>>> the older ones. >>>> >>>> Cheers >>>> Amos >> > >
