On 8 Sep 2015, at 15:27, Ian Lance Taylor wrote: > On Tue, Sep 8, 2015 at 7:20 AM, Iain Sandoe <i...@codesourcery.com> wrote: >> >>> This seems likely to break cross-compilers to Darwin that do not have >>> the system libraries available. I guess I don't care about that if >>> you don't. >> >> I do care about it, but I'm not visualising the case... >> >> AFAICS, when built as a host component for a cross to Darwin from >> non-Darwin, environ would be declared as **environ as usual. >> >> If an implementation includes a compiler targeting Darwin that defines >> __APPLE__ but doesn't provide _NSGetEnviron in its libc, then isn't it >> broken anyway? > > I'm talking about the case of building a cross-compiler where the > system libraries are not available. This is sometimes done as a first > step toward building a full cross-compiler.
I've applied the patch since it solves an immediate problem (and has been requested). Right now, the only case that I can think of when there's a Darwin-hosted statically-linked user-space executable is in bringing up the system itself, in which case one has to build non-standard crts and a statically-linkable libc. Last time I did this was on 10.5 with the darwinbuild stuff, not sure it's even feasible on modern Darwin which is built with a different compiler. It's possible that making the Darwin case conditional on ! defined(__STATIC__) might be sufficient to guard that, but I need to think of some way to test it. Iain
