[issue23072] 2.7.9 multiprocessing compile conflict

2015-04-11 Thread Davin Potts
Davin Potts added the comment: 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. -- resolution: -> out of date status: pending -> closed ___ Python tracker

[issue23072] 2.7.9 multiprocessing compile conflict

2015-02-10 Thread Davin Potts
Changes by Davin Potts : -- status: open -> pending ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mai

[issue23072] 2.7.9 multiprocessing compile conflict

2015-02-08 Thread Davin Potts
Davin Potts added the comment: 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;

[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

[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"