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

Hi Alex,
     as suggested in bugzilla I try to add an extra [] at the end of the
AC_RUN_IFELSE and the configure goes ahead (I report the very simple
patch into bugzilla).

Unfortunately I have a similar issue with the SSL certificate check that
comes from acinclude/lib-checks.m4 (around line 108 and 128). In this
case I add double [[ after AC_LANG_PROGRAM and remove [ from
AC_MSG_RESULT, because the same syntax that I see in configure.ac
(forgive me, but I am not an autotools expert).
By the way this modifications have overcome the error on SSL, but I
found a similar issue in the krb5 checks from the acinclude/krb5.m4 .
I report the same syntax scheme as above and after that the configure
goes well...

So now is the compile steps that fails, I have the following error:

../../src/ssl/gadgets.h:223:7: error: 'Ssl::CertificateProperties'
declared with greater visibility than the type of its field
'Ssl::CertificateProperties::mimicCert' [-Werror=attributes]
../../src/ssl/gadgets.h:223:7: error: 'Ssl::CertificateProperties'
declared with greater visibility than the type of its field
'Ssl::CertificateProperties::signWithX509' [-Werror=attributes]
../../src/ssl/gadgets.h:223:7: error: 'Ssl::CertificateProperties'
declared with greater visibility than the type of its field
'Ssl::CertificateProperties::signWithPkey' [-Werror=attributes]
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]
../../src/anyp/PortCfg.h:14:7: error: 'AnyP::PortCfg' declared with
greater visibility than the type of its field
'AnyP::PortCfg::signingCert' [-Werror=attributes]
../../src/anyp/PortCfg.h:14:7: error: 'AnyP::PortCfg' declared with
greater visibility than the type of its field 'AnyP::PortCfg::signPkey'
[-Werror=attributes]
../../src/anyp/PortCfg.h:14:7: error: 'AnyP::PortCfg' declared with
greater visibility than the type of its field
'AnyP::PortCfg::certsToChain' [-Werror=attributes]
../../src/anyp/PortCfg.h:14:7: error: 'AnyP::PortCfg' declared with
greater visibility than the type of its field
'AnyP::PortCfg::untrustedSigningCert' [-Werror=attributes]
../../src/anyp/PortCfg.h:14:7: error: 'AnyP::PortCfg' declared with
greater visibility than the type of its field
'AnyP::PortCfg::untrustedSignPkey' [-Werror=attributes]
../../src/anyp/PortCfg.h:14:7: error: 'AnyP::PortCfg' declared with
greater visibility than the type of its field
'AnyP::PortCfg::clientVerifyCrls' [-Werror=attributes]
../../src/anyp/PortCfg.h:14:7: error: 'AnyP::PortCfg' declared with
greater visibility than the type of its field 'AnyP::PortCfg::clientCA'
[-Werror=attributes]
../../src/anyp/PortCfg.h:14:7: error: 'AnyP::PortCfg' declared with
greater visibility than the type of its field 'AnyP::PortCfg::dhParams'
[-Werror=attributes]
cc1plus: all warnings being treated as errors
make[3]: *** [PortCfg.lo] Error 1

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?

Thank you for the support,
Stefano.

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
>

-- 
*Stefano Cordibella*
EDALab s.r.l. - Networked Embedded Systems
Strada Le Grazie, 15 - 37134 Verona - Italy
email : stefano.cordibella_at_edalab.it
skype : stefano.cordibella
tel. : +39 045 802 70 85
web : www.edalab.it