Issue 8864: multiprocessing: undefined struct/union member: msg_control (original) (raw)

Issue8864

Created on 2010-05-31 21:42 by srid, last changed 2022-04-11 14:57 by admin. This issue is now closed.

Messages (12)
msg106813 - (view)	Author: Sridhar Ratnakumar (srid)	Date: 2010-05-31 21:42
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
msg106814 - (view)	Author: Sridhar Ratnakumar (srid)	Date: 2010-05-31 21:58
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
msg106820 - (view)	Author: John Levon (movement)	Date: 2010-05-31 23:54
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.
msg106826 - (view)	Author: Martin v. Löwis (loewis) *	Date: 2010-06-01 05:21
Defining _XPG4_2 is surely the wrong thing to do, right? It's an internal flag only, not meant to be used by applications.
msg106833 - (view)	Author: John Levon (movement)	Date: 2010-06-01 12:25
Right, it should be one of the "official" ways of enabling that.
msg106845 - (view)	Author: Sridhar Ratnakumar (srid)	Date: 2010-06-01 16:12
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?
msg106847 - (view)	Author: John Levon (movement)	Date: 2010-06-01 16:40
defining _XOPEN_SOURCE=600 or similar is better, as Martin pointed out.
msg106848 - (view)	Author: Antoine Pitrou (pitrou) *	Date: 2010-06-01 16:47
Would such a workaround also be necessary if we want to add support for recvmsg() to the socket module (as in ), or is it totally unrelated?
msg106849 - (view)	Author: John Levon (movement)	Date: 2010-06-01 16:57
Yes, we would almost certainly want something similar.
msg106861 - (view)	Author: Martin v. Löwis (loewis) *	Date: 2010-06-01 21:13
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.
msg106863 - (view)	Author: John Levon (movement)	Date: 2010-06-01 22:47
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?
msg107078 - (view)	Author: Martin v. Löwis (loewis) *	Date: 2010-06-04 17:23
Fixed in r81692, r81694.