Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Compilation --without-threads fails #49285

Closed
pitrou opened this issue Jan 22, 2009 · 17 comments
Closed

Compilation --without-threads fails #49285

pitrou opened this issue Jan 22, 2009 · 17 comments
Labels
build The build process and cross-build

Comments

@pitrou
Copy link
Member

pitrou commented Jan 22, 2009

BPO 5035
Nosy @amauryfa, @pitrou, @vstinner
Files
  • object_dump_nothread.patch
  • gil_nothread.patch
  • _sqlite_nothread-2.patch
  • _tkinter_nothread.patch
  • 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 2010-03-22.12:08:22.098>
    created_at = <Date 2009-01-22.21:24:21.863>
    labels = ['build']
    title = 'Compilation --without-threads fails'
    updated_at = <Date 2010-03-22.12:08:22.096>
    user = 'https://github.com/pitrou'

    bugs.python.org fields:

    activity = <Date 2010-03-22.12:08:22.096>
    actor = 'vstinner'
    assignee = 'none'
    closed = True
    closed_date = <Date 2010-03-22.12:08:22.098>
    closer = 'vstinner'
    components = []
    creation = <Date 2009-01-22.21:24:21.863>
    creator = 'pitrou'
    dependencies = []
    files = ['12837', '12838', '13431', '13432']
    hgrepos = []
    issue_num = 5035
    keywords = ['patch']
    message_count = 17.0
    messages = ['80379', '80380', '80400', '80401', '80402', '80403', '80404', '80405', '80406', '80407', '80413', '84242', '84244', '84245', '84282', '84292', '101496']
    nosy_count = 5.0
    nosy_names = ['amaury.forgeotdarc', 'pitrou', 'vstinner', 'gpolo', 'jnoller']
    pr_nums = []
    priority = 'normal'
    resolution = 'fixed'
    stage = None
    status = 'closed'
    superseder = None
    type = 'compile error'
    url = 'https://bugs.python.org/issue5035'
    versions = ['Python 2.7']

    @pitrou
    Copy link
    Member Author

    pitrou commented Jan 22, 2009

    libpython2.7.a(object.o): In function _PyObject_Dump': /home/antoine/cpython/__svn__/Objects/object.c:341: undefined reference to PyGILState_Ensure'
    /home/antoine/cpython/svn/Objects/object.c:343: undefined reference
    to `PyGILState_Release'

    @pitrou pitrou added the build The build process and cross-build label Jan 22, 2009
    @pitrou
    Copy link
    Member Author

    pitrou commented Jan 22, 2009

    The problem seems to have appeared with:

    [svn r67802] bpo-3632: the "pyo" macro from gdbinit can now run when the
    GIL is released.

    Patch by haypo.

    diff -r 68d511e1c4bc -r 584e97b40be9 Objects/object.c
    --- a/Objects/object.c  Mon Dec 15 22:47:57 2008 +0100
    +++ b/Objects/object.c  Mon Dec 15 23:29:14 2008 +0100
    @@ -331,8 +331,11 @@
            if (op == NULL)
                    fprintf(stderr, "NULL\n");
            else {
    +               PyGILState_STATE gil;
                    fprintf(stderr, "object  : ");
    +               gil = PyGILState_Ensure();
                    (void)PyObject_Print(op, stderr, 0);
    +               PyGILState_Release(gil);
                    /* XXX(twouters) cast refcount to long until %zd is
                       universally available */
                    fprintf(stderr, "\n"

    @vstinner
    Copy link
    Member

    Oops, here is a fix for my regression.

    @vstinner
    Copy link
    Member

    Why is PyGILState_Ensure() defined in Include/pystate.h in there is not
    thread? PyGILState_Ensure() implementation is conditional (in
    Python/pystate.c). Here is a patch to make the definition optional.

    @vstinner
    Copy link
    Member

    Another patch to fix _sqlite without thread support.

    @vstinner
    Copy link
    Member

    _multiprocessing modules doesn't compile but I don't know how to fix it:

    • conn_poll() has a _save argument, but the argument is not used in
      both conn_poll() implementations (pipe_connection.c and socket_connection.c)
    • Modules/_multiprocessing/semaphore.c contains a lot of functions and
      macros for semaphore managment but it looks like thread support is
      required. Eg. compilation fails on a missing symbol: sem_unlink(). The
      function sem_unlink() is defined in system <semaphore.h> and requires
      -lrt or -lpthread compiler flag.

    @vstinner
    Copy link
    Member

    Here is a patch to remove the unused _save argument of conn_poll()
    function from the _multiprocessing mode. It fixes one of the compilation
    problem without thread support.

    @pitrou
    Copy link
    Member Author

    pitrou commented Jan 23, 2009

    There is already a separate issue for multiprocessing compilation: bpo-3807

    @jnoller
    Copy link
    Mannequin

    jnoller mannequin commented Jan 23, 2009

    Victor - there is already another bug and a pending patchbto fix
    multiprocessing when thread support is enabled. Please do not focus on
    that.

    @vstinner
    Copy link
    Member

    @pitou and @jnoller: Ok ok, fine, I will check bpo-3807.

    @jnoller
    Copy link
    Mannequin

    jnoller mannequin commented Jan 23, 2009

    I've committed the fix for bpo-3807 to resolve the mp issues.

    @vstinner
    Copy link
    Member

    Python trunk is still broken --without-threads. The multiprocessing
    issue (bpo-3807) is now closed, so can someone review (or apply?) my
    patches?

    @vstinner
    Copy link
    Member

    Updated and completed patch for _sqlite module (python trunk).

    @vstinner
    Copy link
    Member

    New patch _tkinter_nothread.patch: fix gcc warnings in _tkinter.

    @gpolo
    Copy link
    Mannequin

    gpolo mannequin commented Mar 27, 2009

    Victor, I have changed your tkinter patch a bit and applied on r70641.

    The issue is marking only python 2.7 right now, aren't these changes
    supposed to be applied 26-maint, py3k and 30-maint too ?

    @vstinner
    Copy link
    Member

    gpolo> Victor, I have changed your tkinter patch a bit and applied on r70641.

    Ok, thanks.

    gpolo> The issue is marking only python 2.7 right now, aren't these changes
    gpolo> supposed to be applied 26-maint, py3k and 30-maint too ?

    Since it only fixes warnings, we don't have to "fix" *-maint versions. But I
    would like to see your fix in py3k (I think that trunk and py3k should be as
    close as possible).

    @vstinner
    Copy link
    Member

    _tkinter patch (r70641) was backported to py3k as r70707. py3k compiles fine without threads.

    @ezio-melotti ezio-melotti transferred this issue from another repository Apr 10, 2022
    Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
    Labels
    build The build process and cross-build
    Projects
    None yet
    Development

    No branches or pull requests

    2 participants