This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author neologix
Recipients BreamoreBoy, SebaM6, jnoller, jr244, neologix
Date 2011-08-28.17:16:26
SpamBayes Score 4.172158e-07
Marked as misclassified No
Message-id <1314551788.0.0.285623923389.issue4028@psf.upfronthosting.co.za>
In-reply-to
Content
Hello,

> there's some issues compiling the multiprocessing module on the SunOS
> I have here, where CMSG_LEN, CMSG_ALIGN, CMSG_SPACE and sem_timedwait
> are absent.

CMSG_LEN and friends should be defined by <sys/socket.h> (as required by POSIX). SunOS 5.10 man page lists them:

http://download.oracle.com/docs/cd/E19253-01/816-5173/socket.h-3head/index.html

But not the SunOS 5.9 version:
http://ewp.rpi.edu/hartford/webgen/sysdocs/C/solaris_9/SUNWaman/hman3head/socket.3head.html

> it looks like simply defining the first three macros like this works

It works, but it's probably not a good idea: if the headers don't define CMSG_LEN and friends, then FD passing will probably not work.
It'd be better to not compile multiprocessing_(sendfd|recvfd) if CMSG_LEN is not defined (patch attached).

> sem_timedwait are absent.

Hmmm.
Do you have the compilation's log?
Normally, if sem_timedwait isn't available, HAVE_SEM_TIMEDWAIT shouldn't be defined, and we should fallback to sem_trywait (by the way, calling sem_trywait multiple times until the timeout expires is not the same has calling sem_timedwait: this will fail in case of heavy contention).
So this should build correctly.

And this seems even stranger when I read Sebastian's message:
"""
so I had to commented out HAVE_SEM_TIMEDWAIT from setup.py, see:
             elif platform.startswith('sunos5'):
                  macros = dict(
                      HAVE_SEM_OPEN=1,
                      HAVE_FD_TRANSFER=1
                      )
                      #HAVE_SEM_TIMEDWAIT=0,
                  libraries = ['rt']
"""

Makes sense.
If we define HAVE_SEMTIMEDWAIT=0, then code guarded by
#ifdef HAVE_SEMTIMEDWAIT

will be compiled, and the linker won't be able to resolve sem_timedwait.
The preprocessor just checks that the symbol is defined, not that it has a non-zero value.
To sum up: could someone with a SunOS box test the attached patch, and post the compilation logs if it still fails?
History
Date User Action Args
2011-08-28 17:16:28neologixsetrecipients: + neologix, jnoller, jr244, BreamoreBoy, SebaM6
2011-08-28 17:16:27neologixsetmessageid: <1314551788.0.0.285623923389.issue4028@psf.upfronthosting.co.za>
2011-08-28 17:16:27neologixlinkissue4028 messages
2011-08-28 17:16:26neologixcreate