[Python-Dev] multiprocessing source not "Unix clean"

skip at pobox.com skip at pobox.com
Sat Jun 14 06:31:34 CEST 2008

>>>>> "Guido" == Guido van Rossum <guido at python.org> writes:

    Guido> On Fri, Jun 13, 2008 at 9:21 AM,  <skip at pobox.com> wrote:
    >> In trying to solve a build problem with the multiprocessing code on
    >> Solaris10 I visited multiprocessing.c in XEmacs and noticed the files all
    >> appear to have Windows line endings.  Should those maybe be stripped to
    >> conform to the other Python source?

    Guido> Ow. definitely.

Yes.  If I have some time Saturday and nobody beats me to it I'll fix this.

    >> FWIW, it appears that Solaris doesn't define SEM_VALUE_MAX but does
    >> define _SEM_VALUE_MAX in sys/params.h.
    >> .../Modules/_multiprocessing/multiprocessing.c: In function 'init_multiprocessing':
    >> .../Modules/_multiprocessing/multiprocessing.c:253: error: 'SEM_VALUE_MAX' undeclared (first use in this function)
    >> .../Modules/_multiprocessing/multiprocessing.c:253: error: (Each undeclared identifier is reported only once
    >> .../Modules/_multiprocessing/multiprocessing.c:253: error: for each function it appears in.)
    >> On Windows the author simple #defines SEM_VALUE_MAX to be LONG_MAX.  I used
    >> a little cpp action to define it:
    >> #ifndef SEM_VALUE_MAX
    >> #  ifdef _SEM_VALUE_MAX
    >> #    define SEM_VALUE_MAX _SEM_VALUE_MAX
    >> #  else
    >> #    define SEM_VALUE_MAX INT_MAX
    >> #  endif
    >> #endif

    Guido> Does this enable you to submit a patch?

Sure, I can submit a patch, though while that got me going I have no real
idea if that is the correct way to worm around the problem.  I sort of think
this is something which should be tested for in configure.  The code above
was just a guess.


More information about the Python-Dev mailing list