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.

classification
Title: 2.7.9 multiprocessing compile conflict
Type: Stage:
Components: Build Versions: Python 2.7
process
Status: closed Resolution: out of date
Dependencies: Superseder:
Assigned To: Nosy List: aab@purdue.edu, davin
Priority: normal Keywords:

Created on 2014-12-17 05:37 by aab@purdue.edu, last changed 2022-04-11 14:58 by admin. This issue is now closed.

Messages (4)
msg232801 - (view) Author: aab (aab@purdue.edu) Date: 2014-12-17 05:37
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
msg232806 - (view) Author: aab (aab@purdue.edu) Date: 2014-12-17 07:01
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".
msg235591 - (view) Author: Davin Potts (davin) * (Python committer) Date: 2015-02-09 05:50
It's a little unclear if one or more of the following is true:
(1) you are having trouble getting the multiprocessing module to build properly on Solaris 2.8;
(2) you are having trouble getting your own code to build in a similar way to the multiprocessing module;
(3) you have indeed found a workaround that works for your situation;
(4) you are requesting a change to the multiprocessing module to better support builds on Solaris 2.8.

Could you help clarify?  If you have found a workaround that would better support builds on Solaris 2.8 then might you also be able to propose a patch?  If not, could you clarify what steps are required to reproduce the issue?
msg240479 - (view) Author: Davin Potts (davin) * (Python committer) Date: 2015-04-11 14:42
Closing this very stale issue as out of date with no response from OP since request months ago for enough info to be able to proceed.
History
Date User Action Args
2022-04-11 14:58:11adminsetgithub: 67261
2015-04-11 14:42:29davinsetstatus: pending -> closed
resolution: out of date
messages: + msg240479
2015-02-10 14:51:22davinsetstatus: open -> pending
2015-02-09 05:50:04davinsetnosy: + davin
messages: + msg235591
2014-12-17 07:01:07aab@purdue.edusetmessages: + msg232806
2014-12-17 05:37:53aab@purdue.educreate