<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jun 27, 2019 at 3:39 PM Siva Chandra <<a href="mailto:sivachandra@google.com">sivachandra@google.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Thu, Jun 27, 2019 at 9:06 AM Zachary Turner <<a href="mailto:zturner@roblox.com" target="_blank">zturner@roblox.com</a>> wrote:<br>
> I guess let me make this concrete: can you propose a specific separation that you have in mind?<br>
><br>
> Keep in mind that even if A doesn’t depend on B, that doesn’t mean that A and B can be separated.  You mentioned that open() and close() would obviously  have to be done at the same time, but it’s much worse than this: The *entire transitive closure* of open() and close() must be done at the same time, and my hypothesis is that this is going to a) be much larger than you expect, and b) be different with different underlying libc implementations.<br>
<br>
Let me change the direction here a little bit. Lets say, for Windows,<br>
you can develop the new libc starting from a clean slate without<br>
having to worry about the redirectors/forwarders. Is that a good<br>
enough place for you to start?<br></blockquote><div>It's probably a good enough place for me to start, yes.  I still have reservations -- even for the Linux case -- about whether it will be possible to make a reasonable separation of library calls in such a way that set A redirects, set B doesn't redirect, and everything works without any issues, but as long as the general community isn't locked into such a model for every platform, then I guess it can be up to the platform owners to work those issues on their own.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
> Then there are more immediate issues.  On Windows specifically, I’m not even sure it’s going to be physically possible to link in two copies of the CRT and have one forward to the other.  If it is possible, it’s very non obvious how to make it work and will likely require a ton of additional machinery.<br>
<br>
No, I do not think we want to mix up CRTs on any platform. At the<br>
least, it will be disruptive to the compiler drivers. Our goal is to<br>
build a CRT with supports statically linked executables on Linux. We<br>
do not intend to mix this new CRT with the CRT from the system libc.<br>
The new CRT might only be useful after a non-trivial part of the libc<br>
has been built. Until then, we have to use the CRT from the system<br>
libc.<br></blockquote><div>How would you perform redirection if both copies are not linked in?  Some sort of out-of-process mechanism?  Or maybe I'm misunderstanding the nature of the redirection you're referring to.</div><div><br></div></div></div>