Re: [Python-Dev] How to fix the incorrect shared library extension on linux for 3.2 and newer?

2013-04-10 Thread Ronald Oussoren

On 4 Apr, 2013, at 14:46, Julian Taylor  wrote:

> The values on macos for these variables still look wrong in 3.3.1rc1:
> 
> ./configure --prefix=/Users/jtaylor/tmp/py3.3.1 --enable-shared
> on macosx-10.8-x86_64
> 
> sys.version_info(major=3, minor=3, micro=1, releaselevel='candidate', 
> serial=1)
> SO .so
> EXT_SUFFIX .so
> SHLIB_SUFFIX 0
> 
> 
> the only correct one here is EXT_SUFFIX, SHLIB_SUFFIX should be .dylib 
> (libpython is a .dylib) and .SO possibly too given for what it was used in 
> the past.

SO is explicitly defined as being the same as EXT_SUFFIX (in Makefile.pre.in 
for 3.3), and is gone in default. 

I'm not sure that SHLIB_SUFFIX is supposed to be because it isn't used other 
than to calculate the suffix to use for extensions and that shouldn't change on 
OSX for backward compatiblity reasons, and if it were changed I'd much rather 
see it changes to something like '.pyext' instead of '.dylib'. But that ship 
has long sailed, the very limited advantages of using a unique filename suffix 
for Python extensions isn't worth the very real breakage of actually changing 
it :-)

Oh, and at least setup.py assumes that 
sysconfig.get_config_var('EXT_SUFFIX').endswith(sysconfig.get_config_var('SHLIB_SUFFIX')).

BTW. This is a problem for a lot of the information you can retrieve with 
sysconfig.get_config_var(), a large subset of the information is only useful 
during the build/installation of Python itself and as none of them are actually 
documented using sysconfig.get_config_var() is somewhat of a black art.

> 
> 3.3.0 also returns wrong values
> SO .so
> EXT_SUFFIX None
> SHLIB_SUFFIX ""

Could you file an issue on the tracker about this? 

Ronald


> ___
> Python-Dev mailing list
> [email protected]
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> http://mail.python.org/mailman/options/python-dev/ronaldoussoren%40mac.com

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] cpython (3.3): don't run frame if it has no stack (closes #17669)

2013-04-10 Thread Antoine Pitrou
On Wed, 10 Apr 2013 23:01:46 +0200 (CEST)
benjamin.peterson  wrote:
> http://hg.python.org/cpython/rev/35cb75b9d653
> changeset:   83238:35cb75b9d653
> branch:  3.3
> parent:  83235:172f825d7fc9
> user:Benjamin Peterson 
> date:Wed Apr 10 17:00:56 2013 -0400
> summary:
>   don't run frame if it has no stack (closes #17669)

Wouldn't it be better with a test?

Regards

Antoine.



> 
> files:
>   Misc/NEWS   |  2 ++
>   Objects/genobject.c |  2 +-
>   2 files changed, 3 insertions(+), 1 deletions(-)
> 
> 
> diff --git a/Misc/NEWS b/Misc/NEWS
> --- a/Misc/NEWS
> +++ b/Misc/NEWS
> @@ -12,6 +12,8 @@
>  Core and Builtins
>  -
>  
> +- Issue #17669: Fix crash involving finalization of generators using yield 
> from.
> +
>  - Issue #17619: Make input() check for Ctrl-C correctly on Windows.
>  
>  - Issue #17610: Don't rely on non-standard behavior of the C qsort() 
> function.
> diff --git a/Objects/genobject.c b/Objects/genobject.c
> --- a/Objects/genobject.c
> +++ b/Objects/genobject.c
> @@ -178,7 +178,7 @@
>  PyObject *yf = NULL;
>  PyFrameObject *f = gen->gi_frame;
>  
> -if (f) {
> +if (f && f->f_stacktop) {
>  PyObject *bytecode = f->f_code->co_code;
>  unsigned char *code = (unsigned char *)PyBytes_AS_STRING(bytecode);
>  
> 



___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] cpython (3.3): don't run frame if it has no stack (closes #17669)

2013-04-10 Thread Benjamin Peterson
2013/4/10 Antoine Pitrou :
> On Wed, 10 Apr 2013 23:01:46 +0200 (CEST)
> benjamin.peterson  wrote:
>> http://hg.python.org/cpython/rev/35cb75b9d653
>> changeset:   83238:35cb75b9d653
>> branch:  3.3
>> parent:  83235:172f825d7fc9
>> user:Benjamin Peterson 
>> date:Wed Apr 10 17:00:56 2013 -0400
>> summary:
>>   don't run frame if it has no stack (closes #17669)
>
> Wouldn't it be better with a test?

Yes, if I could come up with a non-fragile one.

--
Regards,
Benjamin
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com