Re: [squid-users] Cross compilation in version > 3.1

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_at_squid-cache.org 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
>>
>
>
Received on Mon Jan 27 2014 - 18:41:05 MST