[issue23072] 2.7.9 multiprocessing compile conflict

[aab]

New submission from aab:

python-2.7.9/Modules/_multiprocessing/multiprocessing.c
python-2.7.9/Modules/_multiprocessing/semaphore.c

The compile lines for the above two files have -DHAVE_SEM_OPEN=1 
-DHAVE_FD_TRANSFER=1 -DHAVE_SEM_TIMEDWAIT=0 in them.  The cpp code in those 
files uses #ifdef and #ifndef with those symbols commensurate with the 
#define/#undef commands used in 'pyconfig.h'. In my case, the biggest problem 
is the -DHAVE_SEM_TIMEDWAIT=0 which DEFINES that symbol so that the #ifndef 
HAVE_SEM_TIMEDWAIT in semaphore.c fails to do what the coder wanted.  Being 
very lazy, I just hacked the files to use #if SYMBOL and #if ! SYMBOL.  
Worked fine.

Solaris 2.8
Studio 11 Compiler Suite

--  Thanks,
--aab

--
components: Build
messages: 232801
nosy: a...@purdue.edu
priority: normal
severity: normal
status: open
title: 2.7.9 multiprocessing compile conflict
versions: Python 2.7

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23072
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue23072] 2.7.9 multiprocessing compile conflict

[aab]

aab added the comment:

Oh mud in face is me (:@{).  The problem exists but I exacerbated it with some 
patches that worked with the 2.4.3 distribution - removed them.

There is, however, a bit of a saving grace.  An #if/#else/#endif near the top 
of multiprocessor.c #defines HAVE_FD_TRANSFER to be 0 or 1.  Subsequently in 
the file, #if HAVE_FD_TRANSFER is used except for the one near the bottom of 
the file which uses #ifdef HAVE_FD_TRANSFER.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23072
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com