<div dir="ltr"><span style="font-size:14px">Hi Karl,</span><div><span style="font-size:14px">(Just re-sending with CC: swift-dev)</span></div><div><span style="font-size:14px"><br></span><div><div style="font-size:14px">I agree. This solution does not solve multiarch problem.</div><div style="font-size:14px">The installed module map still contains hardcoded arch directory name</div><div style="font-size:14px">of building machine.</div><div style="font-size:14px"><br></div><div style="font-size:14px">e.g. </div><div style="font-size:14px">lib/swift/linux/x86_64/glibc.modulemap built on Ubuntu 15.10</div><div style="font-size:14px"><div><br></div><div>    module ioctl {</div><div>      header &quot;x86_64-linux-gnu/sys/ioctl.h&quot;</div><div>      export *</div><div>    }</div><div><br></div></div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">2016-05-28 4:49 GMT+09:00 Karl Wagner <span dir="ltr">&lt;<a href="mailto:razielim@gmail.com" target="_blank">razielim@gmail.com</a>&gt;</span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">I’m not sure if we could dynamically generate the YAML because of multiarch, and because the GCC triple isn’t always the same as the LLVM triple.<div><br></div><div>For example, you might built ‘armv7-linux-gnueabihf’ for Swift/LLVM, but GCC only has ‘arm-linux-gnueabihf’. </div><div><br></div><div>But yeah, thats a really good find, it’s a flexible solution that would allow the same glibc.modulemap to be used by a host compiler when cross-compiling, and natively on the target.</div><span class="HOEnZb"><font color="#888888"><div><br></div></font></span><div><span class="HOEnZb"><font color="#888888">Karl<br></font></span><div><br><div><blockquote type="cite"><div><div class="h5"><div>On 21 May 2016, at 14:36, rintaro ishizaki via swift-dev &lt;<a href="mailto:swift-dev@swift.org" target="_blank">swift-dev@swift.org</a>&gt; wrote:</div><br></div></div><div><div><div class="h5"><div dir="ltr">Hi all,<div><br></div><div>Recently, a couple of PR are posted regarding</div><div>glibc.modulemap in cross-compiling environment.</div><div><br></div><div><a href="https://github.com/apple/swift/pull/2473" target="_blank">https://github.com/apple/swift/pull/2473</a><br></div><div><a href="https://github.com/apple/swift/pull/2486" target="_blank">https://github.com/apple/swift/pull/2486</a><br></div><div><br></div><div>The problem is that glibc.modulemap contains hardcoded SDKROOT in it.</div><div>To resolve that, how about using virtual file system feature in Clang?</div><div><br></div><div>I mean, prepare YAML like this:</div><div><br></div><span style="font-family:monospace,monospace">{</span><br><span style="font-family:monospace,monospace">  &quot;</span><span style="font-family:monospace,monospace">use-external</span><span style="font-family:monospace,monospace">-names&quot;: false,</span><br><span style="font-family:monospace,monospace">  &quot;roots&quot;: [</span><br><span style="font-family:monospace,monospace">    {</span><br><span style="font-family:monospace,monospace">      &quot;type&quot;: &quot;file&quot;,</span><div><span style="font-family:monospace,monospace">      &quot;name&quot;: &quot;${SYSROOT}/usr/include/module.map&quot;,</span><br><span style="font-family:monospace,monospace">      &quot;external-contents&quot;: &quot;${RSRC}/${platform}/${arch}/glibc.modulemap&quot;</span><br><span style="font-family:monospace,monospace">    }</span><br><span style="font-family:monospace,monospace">  ]</span><br><div><font face="monospace, monospace">}</font></div><font face="monospace, monospace"><div><font face="monospace, monospace"><br></font></div></font>Then, invoke Clang with <font face="monospace, monospace">-ivfsoverlay </font>argument.</div><div><br><div>Of course, we have to dynamically create YAML based on <font face="monospace, monospace">-sdk</font> and <font face="monospace, monospace">-target</font></div><div>argument of the Swift compiler.</div><div>Luckily, Clang provides convenient YAML builder for this:</div><div><a href="http://clang.llvm.org/doxygen/classclang_1_1vfs_1_1YAMLVFSWriter.html" target="_blank">http://clang.llvm.org/doxygen/classclang_1_1vfs_1_1YAMLVFSWriter.html</a></div><div><div>It&#39;s easy and trivial work to build that dynamically.</div></div></div><div><br></div><div>Using this feature, glibc.modulemap can be rather simple.</div><div>No need to specify absolute path.</div><div>It can be simple as /usr/include/module.map in Darwin platforms:</div><div><div><br></div><div><font face="monospace, monospace">    module ctype {</font></div><div><font face="monospace, monospace">      header &quot;ctype.h&quot;</font></div><div><font face="monospace, monospace">      export *</font></div><div><font face="monospace, monospace">    }</font></div></div><div><br></div><div>And, it makes easy to import Clang builtin headers like <font face="monospace, monospace">&quot;limits.h&quot;</font>.</div><div><br></div><div>Here is the PoC code:</div><div><a href="https://github.com/apple/swift/compare/master...rintaro:clang-vfsoverlay" target="_blank">https://github.com/apple/swift/compare/master...rintaro:clang-vfsoverlay</a></div><div>It works, and passes all Swift test suite.</div><div><br></div><div>Current my concerns are:</div><div>* The VFS overlay is the right way in the first place?</div><div>* Since I&#39;m a very newbie in C++ programming, I&#39;m not sure I&#39;m doing right thing in the code.</div><div><br></div><div>Any thought?</div><div><br></div></div></div></div><span class="">
_______________________________________________<br>swift-dev mailing list<br><a href="mailto:swift-dev@swift.org" target="_blank">swift-dev@swift.org</a><br><a href="https://lists.swift.org/mailman/listinfo/swift-dev" target="_blank">https://lists.swift.org/mailman/listinfo/swift-dev</a><br></span></div></blockquote></div><br></div></div></div></blockquote></div><br></div>