<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Nov 6, 2014 at 2:42 PM, Juergen Ributzka <span dir="ltr"><<a href="mailto:juergen@apple.com" target="_blank">juergen@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><div>I would have preferred the library to be moved out of the “Support” folder and have its own top-level library and include folder.</div></div></blockquote><div><br></div><div>+1, you will need to do this if you want to support the autoconf build system.</div><div><br></div><div>----</div><div><br></div><div>Looking at the diff, I now remember why you want to do this. I seem to recall you want to do this because the Mac-specific code in Support defines raise(), __assert_rtn(), and abort(), and that's hostile to embedders like WebKit. Makes sense, it's a gross hack, and I'd be in favor of fixing it if possible. If it weren't for this hack, I would recommend that you just avoid calling PrintStackTraceOnErrorSignal from WebKit.</div><div><br></div><div>Is there some way we can prevent this Mac-specific hack from affecting our library organization? It's not clear to me that the distinction between Support and ToolsSupport is really worth it.</div><div><br></div><div>Most LLVM tools are single threaded and don't need to redirect signals to the current thread. I think it's only the crash recovery logic that needs the signal to be delivered to the current thread. Maybe we should factor out a CrashRecovery library, given that XCode via libclang is basically the only client of this stuff? Does WebKit want to try to recover from JIT assertion failures?</div></div></div></div>