[petsc-dev] Mac OS X El Capitan does not propagate DYLD_LIBRARY_PATH from parent process

[Satish Balay]

[reply to Todd's question 'does the #! line make a difference']

It does not.

Satish

----------
balay at imav^~/junk $ cat env-test.py 
import os
if 'FOOBAR' in os.environ:
  print 'FOOBAR:', os.environ['FOOBAR']
else:
  print 'FOOBAR not in env'

if 'DYLD_LIBRARY_PATH' in os.environ:
  print 'DYLD_LIBRARY_PATH:', os.environ['DYLD_LIBRARY_PATH']
else:
  print 'DYLD_LIBRARY_PATH not in env'
balay at imav^~/junk $ python env-test.py 
FOOBAR: foobar
DYLD_LIBRARY_PATH not in env
balay at imav^~/junk $ 



On Wed, 7 Oct 2015, Satish Balay wrote:

> Well both invocations are weeding out DYLD_LIBRARY_PATH from env list.
> 
> Satish
> 
> --------
> balay at imav^~/junk $ cat env-test.py 
> #!/usr/bin/env python
> 
> import os
> if 'FOOBAR' in os.environ:
>   print 'FOOBAR:', os.environ['FOOBAR']
> else:
>   print 'FOOBAR not in env'
> 
> if 'DYLD_LIBRARY_PATH' in os.environ:
>   print 'DYLD_LIBRARY_PATH:', os.environ['DYLD_LIBRARY_PATH']
> else:
>   print 'DYLD_LIBRARY_PATH not in env'
> balay at imav^~/junk $ export DYLD_LIBRARY_PATH=foobar
> balay at imav^~/junk $ export FOOBAR=foobar
> balay at imav^~/junk $ ./env-test.py 
> FOOBAR: foobar
> DYLD_LIBRARY_PATH not in env
> balay at imav^~/junk $ python env-test.py 
> FOOBAR: foobar
> DYLD_LIBRARY_PATH not in env
> balay at imav^~/junk $ 
> 
> 
> 
> On Wed, 7 Oct 2015, Jed Brown wrote:
> 
> > "Andrs, David" <david.andrs at inl.gov> writes:
> > > ​It looks like it​ when the compiler is invoked from an interpreter (like
> > > bash or python). If we run clang from the command line directly, it works
> > > fine.
> > 
> > From the documentation page, it sounds like
> > 
> > DYLD_LIBRARY_PATH=x ./foo.py
> > 
> > will not propagate the variable, but
> > 
> > DYLD_LIBRARY_PATH=x /usr/bin/python foo.py
> > 
> > will propagate it because /usr/bin/python is not a script (starting with
> > #!).  Is this true?
> > 
> > 
> > How are you invoking the compiler from Python?  (In particular, is
> > Python calling execve directly or is it passing a command line to a
> > shell to expand and execute?)
> > 
>