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

> 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.

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.

-- 
Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir
belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de