Re: [PATCH, libiberty] Fix PR63758 by using the _NSGetEnviron() API on Darwin.

[Mike Stump <mikestump at comcast dot net>]

On Oct 18, 2015, at 3:42 AM, Iain Sandoe <iain@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.

So, I see two different things here.  One is a build of the darwin open source kernel.  I’ve never done that, though, I knew people that did.  I don’t play in this space, so I don’t know how much of a rat hole it is, or if it is even possible anymore.  Really, it should just be a drop a new gcc into the official open source darwin build infrastructure and hit build.  If it didn’t just build before, then it might be a time sink to make it work, I just don’t know.

The other is, it is theoretically nice to be able to build up an entire gcc tool chain for a mac, starting from a linux box.  I usually don’t do this, but, I do a subset, which is a cc1 with no headers and no link or assembly support that fails to build, but works far enough to get past cc1.  This isn’t handy for users, but for a developer, I like to do this from time to time.

I don’t see the case that Ian is concerned about.  Either, they have Apple’s library, and it does include this routine, or, someone is making a replacement OS, and then will need to now provide that routine, if they did not before.  Partial builds without a library are fine, but without a library, you can’t link anything (other than -r) anyway, so I’m not sure it matters that it would fail to link, as it failed before anyway (for example, printf would not be found either).

Kernel builds are special, and they are one of the few things that build static, as does the dyld program).  To test either, I’d recommend either, not worrying about it, life is short, or, if you do care enough, you just gotta roll up you sleeves, as they truly are special.