Re: [squid-users] Re: problem compiling squid 3.2.0.15 + openssl 0.9.8 with llvm-gcc-4.2.1

On 01.03.2012 11:55, YJZ wrote:
>> On 29/02/2012 7:17 p.m., YJZ wrote:
>> > Well, I found the explanation:
>> >
>> > 1.
>>
>> http://stackoverflow.com/questions/7406946/why-is-apple-depricating-openssl-in-macos-10-7-lion
>> >
>> > 2.
>>
>> http://ludovicrousseau.blogspot.com/2011/08/mac-os-x-lion-and-openssl.html
>> >
>> > "OpenSSL should be removed in a later Mac OS X version.
>> >
>> > For projects using OpenSSL on Mac OS X you have two options:
>> >
>> > move from OpenSSL to Common Crypto
>> > provide your own version of OpenSSL in the installer (or use
>> a
>> static link)"
>> >
>> > So my question now is: Which option would squid go with, in order
>> to
>> compile with --enable-ssl on Mac OS X?
>>
>> That makes 5 operating system distributors wanting 3 different
>> crypto
>> systems now.
>>
>> So far the work upstream has been moving slowly in the direction of
>> isolating the SSL pieces into a internal library. Then work can
>> begin on
>> creating alternative wrapping layers to ma for each SSL system.
>> Assistance pushing that redesign forward is very welcome. For now
>> you
>> have a choice between OpenSSL or nothing.
>>
>
> Out of curiosity, what's the third crypto system? The one immediately
> coming to mind is GNUTLS, since I ran into that change-in-direction
> trying to compile wget 1.13.x.
>

Yes, GNUTLS is being requested by Debian and *BSD. RHEL are asking for
some NSS libraries for some/most of the crypto functionality. And now
Mac with CommonCrypto.

> I'm not a programmer, but if someone could come up with the empirical
> wrapper for Common Crypto or GNUTLS on OS X, I could help
> "testdriving".
>
>> >
>> > In the meantime, I tried to get around it without --disable-ssl or
>> without --enable-ssl. In that case, "make" of
>> squid-3.2.0.15-20120228-r11519
>> stops at:
>> >
>> > /bin/sh ../../libtool --tag=CXX --mode=compile g++
>> -DHAVE_CONFIG_H
>> -DDEFAULT_STATEDIR=\"/usr/local/squid/var/run/squid\" -I../..
>> -I../../include
>> -I../../lib -I../../src -I../../include -Wall -Wpointer-arith
>> -Wwrite-strings -Wcomments -Werror -pipe -D_REENTRANT -g -O2 -c -o
>> StrandCoord.lo
>> StrandCoord.cc
>> > libtool: compile: g++ -DHAVE_CONFIG_H
>> -DDEFAULT_STATEDIR=\"/usr/local/squid/var/run/squid\" -I../..
>> -I../../include -I../../lib -I../../src
>> -I../../include -Wall -Wpointer-arith -Wwrite-strings -Wcomments
>> -Werror -pipe
>> -D_REENTRANT -g -O2 -c StrandCoord.cc -fno-common -DPIC -o
>> .libs/StrandCoord.o
>> > In file included from StrandCoord.cc:13:
>> > ../../src/ipc/TypedMsgHdr.h:93: error: array bound is not an
>> integer
>> constant
>> > make[3]: *** [StrandCoord.lo] Error 1
>> > make[2]: *** [all-recursive] Error 1
>> > make[1]: *** [all] Error 2
>> > make: *** [all-recursive] Error 1
>> >
>> > Is this a side-effect of gcc 4.2.1 being a symlink to llvm-gcc on
>> OS X
>> 10.7.x?
>>
>> Uh-oh. CMSG_SPACE() not being a constant is a bit of a worry. What
>> exactly is it defined as on Mac?
>>
>> Amos
>>
>
> I'm not exactly sure how to determine what it's defined as. However,
> a bit of googling turns up the following, that might help shed some
> light:
>
> http://code.google.com/p/nativeclient/issues/detail?id=1080
>
> "Comment 2 by project member mseaborn_at_chromium.org, Oct 22, 2010
>
> This appears to be fixed in newer versions of the headers. In
>
> http://www.opensource.apple.com/source/xnu/xnu-1504.7.4/bsd/sys/socket.h,
> we have:
>
> #define CMSG_DATA(cmsg) ((unsigned char *)(cmsg) + \
> __DARWIN_ALIGN32(sizeof(struct cmsghdr)))
> ...
> #define CMSG_SPACE(l) (__DARWIN_ALIGN32(sizeof(struct cmsghdr)) +
> __DARWIN_ALIGN32(l))
> #define CMSG_LEN(l) (__DARWIN_ALIGN32(sizeof(struct cmsghdr)) + (l))
>
> It uses __DARWIN_ALIGN32() rather than the __DARWIN_ALIGN() used in
> earlier versions."
>
> Based on that comment, I'm linking to the latest version for OS X
> 10.7.3 at
>
> http://www.opensource.apple.com/source/xnu/xnu-1699.22.73/bsd/sys/socket.h,
> which still has the same definitions.

That was what I was looking for. It is down to how llvm implements
__DARWIN_ALIGN32() then. Apparently as a function or something at build
time.

NP: this breaks SMP support and place llvm builds on Mac in the same
wont-compile pile as Windows until we can figure a way to trick it into
believing the fixed-size packet headers are a constant size.

Amos
Received on Wed Feb 29 2012 - 23:05:13 MST