Skip to content

Multiprocessing package build problem on Solaris 10 #47360

Closed
Closed
Multiprocessing package build problem on Solaris 10#47360
Labels
buildThe build process and cross-buildextension-modulesC modules in the Modules dir

Description

@jnoller
jnoller
mannequin
opened on Jun 14, 2008
BPO 3110
Nosy @loewis, @smontanaro, @pitrou, @osvenskan
Files
  • issue_3110.patch
  • explore_sem_value_max.c
    		•

    Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.

    Show more details

    GitHub fields:

    assignee = None
closed_at = <Date 2009-04-02.02:45:22.428>
created_at = <Date 2008-06-14.19:36:15.855>
labels = ['extension-modules', 'build']
title = 'Multiprocessing package build problem on Solaris 10'
updated_at = <Date 2009-04-02.02:45:22.426>
user = 'https://bugs.python.org/jnoller'

    bugs.python.org fields:

    activity = <Date 2009-04-02.02:45:22.426>
actor = 'jnoller'
assignee = 'jnoller'
closed = True
closed_date = <Date 2009-04-02.02:45:22.428>
closer = 'jnoller'
components = ['Extension Modules']
creation = <Date 2008-06-14.19:36:15.855>
creator = 'jnoller'
dependencies = []
files = ['11361', '12391']
hgrepos = []
issue_num = 3110
keywords = ['patch']
message_count = 13.0
messages = ['68210', '68330', '71985', '72395', '72399', '72403', '72405', '72408', '72409', '72410', '73011', '78006', '85141']
nosy_count = 6.0
nosy_names = ['loewis', 'skip.montanaro', 'pitrou', 'osvenskan', 'roudkerk', 'jnoller']
pr_nums = []
priority = 'high'
resolution = 'fixed'
stage = None
status = 'closed'
superseder = None
type = 'compile error'
url = 'https://bugs.python.org/issue3110'
versions = ['Python 2.6', 'Python 3.0']

    Activity

    1. jnoller commented on Jun 14, 2008

      @jnoller
      jnollermannequin
      on Jun 14, 2008
      MannequinAuthor

      Per skip's email:
      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
    2. jnoller
      added
      extension-modulesC modules in the Modules dir
      buildThe build process and cross-build
      on Jun 14, 2008

    3. smontanaro commented on Jun 17, 2008

      @smontanaro
      smontanaro
      on Jun 17, 2008
      Contributor

      Jesse> Per skip's email:
      Jesse> FWIW, it appears that Solaris doesn't define SEM_VALUE_MAX but does
      Jesse> define
      Jesse> _SEM_VALUE_MAX in sys/params.h.

      ...

      Thanks for submitting the bug report. I wonder why the processing module
      installs on Solaris10 but multiprocessing fails to compile. Did the
      SEM_VALUE_MAX code change between the two variants?

      Skip

    4. jnoller
      self-assigned this
      on Jun 19, 2008

    5. pitrou commented on Aug 26, 2008

      @pitrou
      pitrou
      on Aug 26, 2008
      Member

      FWIW, this is what I find on a Solaris box.

      ./sys/param.h:#define _SEM_VALUE_MAX INT_MAX
      ./sys/sysconfig.h:#define _CONFIG_SEM_VALUE_MAX 21 /* max.
      value a semaphore may have */
      ./sys/unistd.h:#define _SC_SEM_VALUE_MAX 37
      ./limits.h:#define _POSIX_SEM_VALUE_MAX 32767

    6. jnoller commented on Sep 3, 2008

      @jnoller
      jnollermannequin
      on Sep 3, 2008
      MannequinAuthor

      Raising this to RB, we should not RC without the MP module properly
      compiling

    7. jnoller
      added
      release-blocker
      on Sep 3, 2008

    8. pitrou commented on Sep 3, 2008

      @pitrou
      pitrou
      on Sep 3, 2008
      Member

      I suggest committing a patch which falls back to _SEM_VALUE_MAX and see
      how the Solaris buildbot reacts.

    9. jnoller commented on Sep 3, 2008

      @jnoller
      jnollermannequin
      on Sep 3, 2008
      MannequinAuthor

      Anyone mind reviewing the attached patch? This should resolve the solaris
      compile issue. I used skip's suggested code - I removed the #ifdef solaris
      at AP's suggestion.

    10. pitrou commented on Sep 3, 2008

      @pitrou
      pitrou
      on Sep 3, 2008
      Member

      I recompiled and tested multiprocessing both under Windows and Linux
      with this patch, no problems detected. +1 for applying it.

    11. smontanaro commented on Sep 3, 2008

      @smontanaro
      smontanaro
      on Sep 3, 2008
      Contributor

      I can confirm that Jesse's patch allows multiprocessing to compile on
      Solaris 10. Note, however, that there are other symbolic constants
      defined which contain "SEM_VALUE_MAX", all with widely differing
      underlying values:

      % find /usr/include -name '*.h' | xargs egrep SEM_VALUE_MAX
/usr/include/sys/param.h:#define        _SEM_VALUE_MAX          INT_MAX
/usr/include/sys/sysconfig.h:#define    _CONFIG_SEM_VALUE_MAX   21 
/* max. value a semaphore may have */
/usr/include/sys/unistd.h:#define       _SC_SEM_VALUE_MAX          
37
/usr/include/limits.h:#define   _POSIX_SEM_VALUE_MAX    32767

      How do we know that _SEM_VALUE_MAX is the proper rvalue to use when
      #define-ing SEM_VALUE_MAX?

      Richard, as the author of the original processing module do you have
      something to contribute to this discussion? You've been completely
      silent on this issue.

    12. jnoller commented on Sep 3, 2008

      @jnoller
      jnollermannequin
      on Sep 3, 2008
      MannequinAuthor

      Skip - Richard has been unavailable a good chunk of the summer. I don't
      know when he will be online again.

    13. jnoller commented on Sep 3, 2008

      @jnoller
      jnollermannequin
      on Sep 3, 2008
      MannequinAuthor

      I've committed the patch in r66184 on trunk, 66185 py3k. Skip raises a
      good point, therefore I'll leave this open but lower from a blocker.

    14. jnoller
      removed
      release-blocker
      on Sep 3, 2008

    15. loewis commented on Sep 11, 2008

      @loewis
      loewismannequin
      on Sep 11, 2008
      Mannequin

      According to POSIX, if no determinate value for SEM_VALUE_MAX can be
      given, the actual value should be queried with
      sysconf(_SC_SEM_VALUE_MAX), and SEM_VALUE_MAX should not be defined;
      this is in particular the case when the value depends on the system
      configuration (such as available memory). _POSIX_SEM_VALUE_MAX specifies
      the minimum value guaranteed by POSIX.

      Now, it is not plausible why SEM_VALUE_MAX should vary by installation,
      as it just depends on what integer type is used to represent the
      counter. So more likely, Sun wrote its header files at a time when the
      spec was not finished, so they didn't want to clutter the global namespace.

      IOW, I think the patch is fine as it stands. If you are over-cautious,
      you should test whether _SC_SEM_VALUE_MAX is defined, and use sysconf in
      that case, and only fall back to _SEM_VALUE_MAX, then
      _POSIX_SEM_VALUE_MAX, then fail, if sysconf isn't available.

      If you do make this change, please stop using Py_BuildValue to convert a
      C int to a Python int; use PyInt_FromLong instead.

    16. osvenskan commented on Dec 18, 2008

      @osvenskan
      osvenskanmannequin
      on Dec 18, 2008
      Mannequin

      I'm facing the same problem (getting a good definition of SEM_VALUE_MAX)
      for my posix_ipc extension. The patch presented here will get the
      compiler to shut up on OpenSolaris, but not for the reason you think. At
      least, that's the way I see it.

      On OpenSolaris (2008.05 is what I'm testing with), _SEM_VALUE_MAX is
      indeed #defined in sys/param.h, but it's inside this #ifdef on line 322:

      #if (defined(_KERNEL) || defined(_KMEMUSER))

      Since multiprocessing.c doesn't #define either of these, both
      SEM_VALUE_MAX and _SEM_VALUE_MAX will remain undefined and so the patch
      will always fall back to INT_MAX.

      IMHO, given the choice between #defining _KERNEL or _KMEMUSER and
      calling sysconf(_SC_SEM_VALUE_MAX), I feel safer doing the latter.

      I did a survey of all the operating systems to which I have access
      (OpenSolaris 2008.05, OS X 10.5.5, RHEL?, Ubuntu 8.04, and FreeBSD 7).
      OpenSolaris is the only one that doesn't #define SEM_VALUE_MAX, and on
      all systems except for the possibly Red Hattish one,
      sysconf(_SC_SEM_VALUE_MAX) returned the same value as the definition of
      SEM_VALUE_MAX. I attached my code & results.

    17. jnoller commented on Apr 2, 2009

      @jnoller
      jnollermannequin
      on Apr 2, 2009
      MannequinAuthor

      Additional protection checked in in r71022

    18. jnoller
      closed this as completedon Apr 2, 2009
    19. ezio-melotti
      transferred this issue fromon Apr 10, 2022
    Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

    Metadata

    Metadata

    Assignees

    No one assigned

      Labels

      buildThe build process and cross-buildextension-modulesC modules in the Modules dir

      Projects

      No projects

        Milestone

        No milestone

        Relationships

        None yet

        Development

        No branches or pull requests

        Issue actions