<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><a href="https://lists.swift.org/pipermail/swift-users/2015-December/000020.html" class="">https://lists.swift.org/pipermail/swift-users/2015-December/000020.html</a><div class=""><br class=""></div><div class="">(Sorry I don't have the reply link handy)</div><div class=""><br class=""></div><div class=""><blockquote type="cite" class="">Joe Groff wrote:</blockquote><blockquote type="cite" class=""> Porting to musl libc might be interesting too, but I'm not sure how dependent the core libs are/will be on glibc stuff.</blockquote><br class=""></div><div class="">I'm going to do a braindump on this. I spent several hours researching a musl port. I've decided I won't actually do one, but my research may be useful to the next person who picks up the torch.</div><div class=""><br class=""></div><div class="">The real problem with musl is that the swift ecosystem presumes linux == glibc, and it presumes this very, very, very deeply and very, very, broadly. Divorcing those two concepts is going to be very very radical at this stage, and this comes from a person who makes radical changes for fun.</div><div class=""><br class=""></div><div class=""># Ecosystem woes</div><div class=""><br class=""></div><div class="">Probably the biggest problem is the ecosystem. What people are actually doing with their Swift modules they write is</div><div class=""><br class=""></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class="">#if os(Linux)</div><div class="">import Glibc</div><div class=""><div class="">#else </div></div><div class="">import Darwin</div><div class=""><div class="">#endif</div></div></blockquote><div class=""><br class=""></div><div class="">For example in this tutorial <a href="http://blog.krzyzanowskim.com/2015/12/04/swift-package-manager-and-linux-compatible/" class="">here</a>. So unless you want to prosecute this "linux is not glibc" patch across every project in the Swift ecosystem you're gonna have a bad time. IMO there should be some better way to handle "pick a libc" in the package manager or something, but I'm not completely sure what it is.</div><div class=""><br class=""></div><div class=""># The problem started in LLVM</div><div class=""><br class=""></div><div class="">The module authors aren't stupid arbitrarily. They have learned this "linux == glibc" philosophy from the swift package itself, and ultimately it even goes all the way to llvm:</div><div class=""><br class=""></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class=""> // On linux we have a weird situation. The stderr/out/in symbols are both</div><div class=""> // macros and global variables because of standards requirements. So, we</div><div class=""> // boldly use the EXPLICIT_SYMBOL macro without checking for a #define first.</div><div class="">#if defined(__linux__) and !defined(__ANDROID__)</div></blockquote><div class=""><br class=""></div><div class="">Whereas what we wanted was:</div><div class=""><br class=""></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class="">#if defined(__GLIBC__)</div><div class=""><br class=""></div></blockquote>And the comment is not quite accurate either for musl, but I'm not enough of a language lawyer to be able to fix it.<div class=""><br class=""></div><div class="">Anyway, I have written this patch (attached) which does build llvm with musl, although it breaks glibc builds, so obviously it's not mergeable. There are similar patches floating around, but they're out of date AFAIK. This one is current.</div><div class=""><br class=""></div><div class=""># One does not simply</div><div class=""><br class=""></div><div class="">Research suggests that I am not the first to be vaguely interested in getting musl into the llvm family tree of projects/languages, based on the patches floating around for various components. And some downstream people have actually managed to build various musl-hacked llvms and llvm-backed languages (Alpine's llvm, rust-musl). So why can't we get it done upstream where it belongs?</div><div class=""><br class=""></div><div class="">Well, there is a requirements conflict:</div><div class=""><br class=""></div><div class=""><ul class="MailOutline"><li class="">llvm/clang (and I assume Swift) want some kind of strongish guarantee against borking the behavior on other non-musl systems that work just fine already, thank you</li><li class="">musl refuses to implement #if __MUSL__ and <a href="http://wiki.musl-libc.org/wiki/FAQ#Q:_why_is_there_no_MUSL_macro_.3F" class="">calls the feature a bug</a>.</li></ul></div><div class=""><br class=""></div><div class="">These both seem reasonable independently but when you put them together it's kind of a heavy rock / immovable object situation.</div><div class=""><br class=""></div><div class=""># tl;dr</div><div class=""><br class=""></div><div class="">* swift at every level from third-party packages to low-level llvm assumes linux == glibc</div><div class="">* a requirements conflict prevents those concepts from getting properly divorced in relevant upstream projects</div><div class="">* solving this requires a tower of hacks even a crazy person like me can't stomach</div><div class=""><br class=""></div><div class="">As a result of all this, I have resigned myself to maintaining the glibc dependency for the forseeable future.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""></div></body></html>