[Common-dev] CR: fix MacOSX build

Bob Clark bobclark at real.com
Thu May 13 12:31:35 PDT 2004


It's a touch more convoluted than that. :-(

With OS X 10.2 and below, we need to typedef socklen_t. But with OS X 
10.3 and above, socklen_t is defined for us. The macro logic necessary 
for this can be seen in common/netio/pub/platform/unix/unix_net.h:

#if !defined _HPUX && !defined _AIX43 && (!defined _MAC_UNIX || ( 
defined(_MAC_UNIX) && ( !defined(MAC_OS_X_VERSION_10_3) || 
(MAC_OS_X_VERSION_MAX_ALLOWED < MAC_OS_X_VERSION_10_3) ) ) )
typedef unsigned int socklen_t;
#endif


(As an aside, for OS X 10.3 and above, use SYSTEM_ID macos-gcc3-xcode 
instead of macos-gcc3-pb.)

--Bob


On Thursday, May 13, 2004, at 12:06 PM, Tom Marshall wrote:

> This fixes the MacOSX build for common/netio on the HEAD.  I'll check 
> it in
> this afternoon unless there are objections.
>
> ----- Forwarded message from Tom Marshall <tmarshall at real.com> -----
>
> Looks like the problem is MacOS doesn't define a scoklen_t.  This is 
> surely
> due to it's FreeBSD heritage (older FreeBSD versions have the same 
> issue).
> If you have a MacOSX box, can you try this patch?
>
>   diff -u -d -b -B -r1.1 nettypes.h
>   --- pub/platform/posix/nettypes.h       20 Apr 2004 16:46:31 -0000   
>    1.1
>   +++ pub/platform/posix/nettypes.h       13 May 2004 18:25:01 -0000
>   @@ -76,7 +76,8 @@
>    #define SOCKERR_CONNRESET   EPIPE
>    #define SOCKERR_EOF         -1
>    /* NB: Platforms needing socklen_t include FreeBSD < 4.0 and 
> Solaris < 8.0 */
>   -#if defined(_FREEBSD2) || defined(_FREEBSD3) || defined(_SOLARIS26) 
> || defined(_SOLARIS27)
>   +#if defined(_FREEBSD2) || defined(_FREEBSD3) || defined(_MAC_UNIX) 
> || \
>   +    defined(_SOLARIS26) || defined(_SOLARIS27)
>    typedef int socklen_t;
>    #endif
>    #if defined(_HPUX)
>
> On Thu, May 13, 2004 at 10:49:57AM -0700, hwatson wrote:
>> Here's the build.
>
> ----- End forwarded message -----
>
> -- 
> There are two ways of constructing a software design. One is to make 
> it so
> simple that there are obviously no deficiencies; the other is to make 
> it so
> complicated that there are no obvious deficiencies. The first method 
> is far
> more difficult.
>         -- C. A. R. Hoare, 1981
> <signature.asc>_______________________________________________
> Common-dev mailing list
> Common-dev at lists.helixcommunity.org
> http://lists.helixcommunity.org/mailman/listinfo/common-dev




More information about the Common-dev mailing list