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

[Satish Balay]

On Wed, 7 Oct 2015, Jed Brown wrote:

> Satish Balay <balay at mcs.anl.gov> writes:
> 
> > And it works fine from C code.
> 
> Yes, but /usr/bin/python is also C code, so how does the OS recognize
> it?  Is it by name, or some token, or some heuristic?  Does linking my
> program to libpython.so cause the OS to futz with my environment?  Does
> naming my C program "python" change its environment?  This "feature"
> seems horribly inconsistent and ineffective.  I'd like to hear the
> rationale for it.

No idea what the rationale is - but here are some more experiments..

>>>>>>
balay at imav^~/junk $ export DYLD_LIBRARY_PATH=foobar
balay at imav^~/junk $ env |grep DYLD
balay at imav^~/junk $ printenv  |grep DYLD
balay at imav^~/junk $ echo $DYLD_LIBRARY_PATH
foobar
balay at imav^~/junk $ 
<<<<<<

So 'env' and 'printenv' cannont find DYLD_LIBRARY_PATH? - but 'echo' can?

Trying out code from http://stackoverflow.com/questions/2085302/printing-all-environment-variables-in-c-c

>>>>>>>>>
balay at imav^~/junk $ cat env2.c
#include <stdio.h>

int main(int argc, char **argv, char** envp)
{
  char** env;
  for (env = envp; *env != 0; env++)
    {
      char* thisEnv = *env;
      printf("%s\n", thisEnv);    
    }
  return(0);
}
balay at imav^~/junk $ gcc env2.c
alay at imav^~/junk $ ./a.out |grep DYLD
DYLD_LIBRARY_PATH=foobar
balay at imav^~/junk $ 

<<<<<<<<<<

This works - but not env, printenv?

Satish