but no one but me seems to build python the unix-y way on darwin/macosx anymore
so i guess i'm the only one that cares
btw, python without environ defined makes all third party python bindings segfault
this has been pissing me off for months
only tracked it down yesterday
here's my lackluster patch
feel free to find something more apropos to conditionalize the diff with and commit it 
or not
i don't care anymore

Wich MacOsx/python version does this affect?

Python from svn trunk (r54849) on a Tiger (10.4.9) seems to define os.environ properly, with and without the patch.

right now, i'm using macosx 10.2/python 2.4 
but this should affect any macosx/darwin that's building python as a library instead of a framework
meaning the symbol _environ will be completely undefined and no third party python bindings will work
from posixmodule.c
 /* On Darwin/MacOSX a shared library or framework has no access to
 ** environ directly, we must obtain it with _NSGetEnviron().
 */
however, the #ifdef that comment is contained in only takes the framework into consideration

The patch looks sane, I'm assigning the bug to myself to help me remember 
that I should take a closer look.

I won't commit this patch because I cannot reproduce the problem.

The python trunk works fine for my in these build configurations: unix-
build (static library), unix-build (shared library), framework build.

All of this on OSX 10.5. 

Can you please provide more information on how to reproduce the problem 
(os releases, which version of python, how to build, what should I do to 
get the segfault you mention)?

I can reproduce this with a unix build of python2.5:

* Install a unix build of python 2.5 (--with-pydebug) as 
  /opt/python2.5-dbg

* Install pyobjc 2.2-dev (from PyObjC's subversion repository)

* Build the addressbook plugin example in pyobjc-framework-AddressBook

* Install said plugin and open the AddressBook application

* The plugin won't load, and the console will mention that _environ 
  cannot be found.

I haven't tested this with python 2.6 or later yet, 2.5 happens to be 
the version of Python I test PyObjC with.

@Ronald is this still a problem or can this be closed?

This is still a problem.

Technically this only works accidently with a framework build, code that expects that '_environ' is defined in a shared library on OSX is broken.

I have also been experiencing this problem with _environ (using the latest Python - 2.7.2), and this patch works great. I'd love to see it committed so that I don't have to patch Python.

I confirm that under Python 2.7.2 while trying to build a 3rd-party package (from rdkit.org) I get the error


Linking CXX shared library ../../lib/libRDBoost.dylib
ld: warning: path '/usr/local/lib/libpython2.7.a' following -L not a directory
Undefined symbols:
  "_environ", referenced from:
      _initposix in libpython2.7.a(posixmodule.o)
     (maybe you meant: cstring=ignore_environment)
ld: symbol(s) not found
collect2: ld returned 1 exit status

My Python-2.7 was configured with "./configure" and is not a framework install. I applied the patch to my local 2.7 copy and the third party package builds without a problem.

I can also confirm this patch is required to build py2cairo on OSX with Python2.7.2 when --enable-framework is not used.

I appear to be running into this as well in py2app, with the current 2.7 tree and a --enable-shared build py2app's updates to the environment (with setenv from C code) won't be seen by Python, even though Python is initialized after the call to setenv.

The patch doesn't work for me though: with the patch the build fails because os.environ no longer contains 'PATH'. I'm looking into this issue.

The basic idea of the patch seems sane, both posixmodule.c and crt_externs.h mention that the call is needed for shared libraries.

The patch didn't work for me because I manually applied and missed a bit. The patches fixes <https://bitbucket.org/ronaldoussoren/py2app/issue/81> for me, and the environ(7) manpage also indicates that the call to _NSEnvironment is needed in shared libraries. 

I've attached a slightly different version of the patch that only enabled the _NSGetEnvironment path for shared library builds (--enable-shared and --enable-framework) and doesn't change anything for the default static builds.

Ned: I think this is a bugfix and should be merged into all active branches. Do you agree? If so, I'll apply the patch.

Ronald: the patch?

LGTM and I agree that it should be considered a bug fix.

New changeset 864b9836dae6 by Ronald Oussoren in branch '2.7':
Issue #1602133: 'environ' is not really available with shared libraries on OSX
http://hg.python.org/cpython/rev/864b9836dae6

New changeset ea9fd9c9c677 by Ronald Oussoren in branch '3.2':
Issue #1602133: 'environ' is not really available with shared libraries on OSX
http://hg.python.org/cpython/rev/ea9fd9c9c677

New changeset 106d1d79c853 by Ronald Oussoren in branch '3.3':
Issue #1602133: 'environ' is not really available with shared libraries on OSX (merge from 3.2)
http://hg.python.org/cpython/rev/106d1d79c853

New changeset b41e3e2bd4cc by Ronald Oussoren in branch 'default':
Issue #1602133: 'environ' is not really available with shared libraries on OSX (merge from 3.3)
http://hg.python.org/cpython/rev/b41e3e2bd4cc