[issue23072] 2.7.9 multiprocessing compile conflict

2014-12-16 Thread 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 
<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

2014-12-16 Thread 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 
<http://bugs.python.org/issue23072>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com