There is apparently a regression on ^/trunk with multiprocessing on solaris10-x86 today. (used to work a few weeks before)

cc -Kpic -OPT:Olimit=0 -g -DNDEBUG -O -IModules/_multiprocessing -I. -IInclude -I./Include -I/export/home/apy/rrun/build/activepyt
hon-svn-trunk/build/pyhg_trunk-solaris10-x86-hgtip27-rrun/python/Include -I/export/home/apy/rrun/build/activepython-svn-trunk/buil
d/pyhg_trunk-solaris10-x86-hgtip27-rrun/python -c /export/home/apy/rrun/build/activepython-svn-trunk/build/pyhg_trunk-solaris10-x86-hgtip27-rrun/python/Modules/_multiprocessing/multiprocessing.c -o build/temp.solaris-2.10-i86pc-2.7/export/home/apy/rrun/build/activepython-svn-trunk/build/pyhg_trunk-solaris10-x86-hgtip27-rrun/python/Modules/_multiprocessing/multiprocessing.o
cc: Warning: illegal option -OPT:Olimit=0
"/export/home/apy/rrun/build/activepython-svn-trunk/build/pyhg_trunk-solaris10-x86-hgtip27-rrun/python/Modules/_multiprocessing/multiprocessing.c", line 126: undefined struct/union member: msg_control
"/export/home/apy/rrun/build/activepython-svn-trunk/build/pyhg_trunk-solaris10-x86-hgtip27-rrun/python/Modules/_multiprocessing/multiprocessing.c", line 126: warning: improper pointer/integer combination: op "="
"/export/home/apy/rrun/build/activepython-svn-trunk/build/pyhg_trunk-solaris10-x86-hgtip27-rrun/python/Modules/_multiprocessing/multiprocessing.c", line 127: undefined struct/union member: msg_controllen
"/export/home/apy/rrun/build/activepython-svn-trunk/build/pyhg_trunk-solaris10-x86-hgtip27-rrun/python/Modules/_multiprocessing/multiprocessing.c", line 130: warning: implicit function declaration: CMSG_FIRSTHDR
"/export/home/apy/rrun/build/activepython-svn-trunk/build/pyhg_trunk-solaris10-x86-hgtip27-rrun/python/Modules/_multiprocessing/multiprocessing.c", line 130: warning: improper pointer/integer combination: op "="
"/export/home/apy/rrun/build/activepython-svn-trunk/build/pyhg_trunk-solaris10-x86-hgtip27-rrun/python/Modules/_multiprocessing/multiprocessing.c", line 134: improper member use: msg_controllen
"/export/home/apy/rrun/build/activepython-svn-trunk/build/pyhg_trunk-solaris10-x86-hgtip27-rrun/python/Modules/_multiprocessing/multiprocessing.c", line 135: warning: implicit function declaration: CMSG_DATA
"/export/home/apy/rrun/build/activepython-svn-trunk/build/pyhg_trunk-solaris10-x86-hgtip27-rrun/python/Modules/_multiprocessing/multiprocessing.c", line 161: undefined struct/union member: msg_control
"/export/home/apy/rrun/build/activepython-svn-trunk/build/pyhg_trunk-solaris10-x86-hgtip27-rrun/python/Modules/_multiprocessing/multiprocessing.c", line 161: warning: improper pointer/integer combination: op "="
"/export/home/apy/rrun/build/activepython-svn-trunk/build/pyhg_trunk-solaris10-x86-hgtip27-rrun/python/Modules/_multiprocessing/multiprocessing.c", line 162: undefined struct/union member: msg_controllen
"/export/home/apy/rrun/build/activepython-svn-trunk/build/pyhg_trunk-solaris10-x86-hgtip27-rrun/python/Modules/_multiprocessing/multiprocessing.c", line 165: warning: improper pointer/integer combination: op "="
"/export/home/apy/rrun/build/activepython-svn-trunk/build/pyhg_trunk-solaris10-x86-hgtip27-rrun/python/Modules/_multiprocessing/multiprocessing.c", line 169: improper member use: msg_controllen
cc: acomp failed for /export/home/apy/rrun/build/activepython-svn-trunk/build/pyhg_trunk-solaris10-x86-hgtip27-rrun/python/Modules/_multiprocessing/multiprocessing.c

Platforms affected:
  SunOS ginsu 5.10 Generic_125101-10 i86pc i386 i86pc
  SunOS nail 5.8 Generic_117350-55 sun4u sparc SUNW,Sun-Fire-280R

Compiler used:
bash-2.03$ which cc                
/opt/SUNWspro/bin//cc
bash-2.03$ cc -V   
cc: Sun C 5.7 2005/01/07
usage: cc [ options] files.  Use 'cc -flags' for details

This seems to have been introduced by fix for Issue1759169

This appears to be one of the few cases where there's incompatibilities between different versions of the standards. Old BSD sockets use msg_accrights*, whereas the more modern way is msg_control*
pointing to a struct cmsghdr.

In terms of user/kernel interface, this difference is encoded as a MSG_XPG4_2 flag via a __xnet_recvmsg() re-define depending upon #ifdef _XPG4_2.

The result being that it's impossible to use C99 and a modern struct msghdr together. This is less than ideal and I'm following it up internally.

In terms of getting Python building again, it should be sufficient to define _XPG4_2 for the multiprocessing module compile only.

Defining _XPG4_2 is surely the wrong thing to do, right? It's an internal flag only, not meant to be used by applications.

Right, it should be one of the "official" ways of enabling that.

On 2010-05-31, at 4:54 PM, John Levon wrote:

> In terms of getting Python building again, it should be sufficient to define _XPG4_2 for the multiprocessing module compile only.

I can verify that the following patch works around this issue (for now);

--- python.org/Modules/_multiprocessing/multiprocessing.c       2010-05-31 17:04:08.499559243 -0700
+++ python/Modules/_multiprocessing/multiprocessing.c   2010-05-31 17:04:28.568723434 -0700
@@ -6,6 +6,11 @@
  * Copyright (c) 2006-2008, R Oudkerk --- see COPYING.txt
  */

+/* 
+ * Workaround for http://bugs.python.org/issue8864#msg106820
+ */
+#define _XPG4_2
+
 #include "multiprocessing.h"

 #ifdef SCM_RIGHTS

On 2010-06-01, at 5:25 AM, John Levon wrote:

> Right, it should be one of the "official" ways of enabling that.

So I presume this should be the right way to fix this bug?

defining _XOPEN_SOURCE=600 or similar is better, as Martin pointed out.

Would such a workaround also be necessary if we want to add support for recvmsg() to the socket module (as in issue6560), or is it totally unrelated?

Yes, we would almost certainly want something similar.

Most likely, we wouldn't be able to support recvmsg on Solaris. We would need to run configure tests to determine whether the APIs are available, and that would require defining _XOPEN_SOURCE in pyconfig.h.in, which (according to #1759169) we must not do.

It's not clear why you'd need configure tests, but you could easily add the define in the body of the autoconf test AFAIK - is there a reason this is difficult?

Fixed in r81692, r81694.