Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 21 Apr 2014 09:33:47 +0200
From: Szabolcs Nagy <>
Subject: Re: static musl-based gdb and -fPIC

* <> [2014-04-20 17:39:37 -0400]:
> For the record: python's Modules/posixmodule.c has a static
> implementation of posix_close that is incompatible with musl's.  My

yes they define posix_ prefixed symbols for internal use
which are reserved names for the c implementation when
any standard headers are included

the next posix standard defines posix_close so this is a
real collision (and will be an issue with every conformant
libc), but all the other posix_ symbols are wrong there too

> first take on that was to make python use musl's posix_close, which
> resulted in a very subtle bug leading to a segmentation fault (not
> to mention all of those lost hours...)  Renaming the module's
> posix_close to __posix_close solved the problem.  The code that

these functions have nothing to do with libc: they operate on
python objects

the symbols should be just renamed but your solution is wrong:
the __ prefix is still in the reserved name space

use s/posix_/pyposix_/ or similar

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.