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@xxxxxxxxxxxx, 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
