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

On Sat, Jun 14, 2008 at 12:31 AM, wrote:

...

...

...

...

...

"Guido" == Guido van Rossum writes:

Guido> On Fri, Jun 13, 2008 at 9:21 AM, 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.

Skip

I filed http://bugs.python.org/issue3110 for the solaris issue. The best way to fix this is to patch setup.py to in the multiprocessing section to account for the solaris issue. -jesse