[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 21 Apr 2014 09:33:47 +0200
From: Szabolcs Nagy <nsz@...t70.net>
To: musl@...ts.openwall.com
Subject: Re: static musl-based gdb and -fPIC
* writeonce@...ipix.org <writeonce@...ipix.org> [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.
