<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">Hi William,</div><div class="gmail_quote"><br></div><div class="gmail_quote">On Tue, Dec 8, 2015 at 8:00 PM, William Dillon via swift-dev <span dir="ltr">&lt;<a href="mailto:swift-dev@swift.org" target="_blank">swift-dev@swift.org</a>&gt;</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">Hi all,<br><br>I’ve been working on trying to get Swift to compile on ARMv7 (armv7l specifically, not sure if other variants will work as well).  I’ve gotten pretty far, but I ran a cross an issue that has me a little confused.  For convenience, here’s the bug that has some of my messages in the comments: <a href="https://bugs.swift.org/browse/SR-40" target="_blank">https://bugs.swift.org/browse/SR-40</a> and here’s my Github fork if you want to play along at home: <a href="https://github.com/hpux735/swift" target="_blank">https://github.com/hpux735/swift</a>  By the way, I’m compiling on an Nvidia tegra TK2 development board with 2GB of ram and a 25GB swapfile on an external SSD.  This brings native compile times down to reasonable levels.  I was compiling on the BeagleBone Black formerly, and that was painful (like over a day for LLVM).<br><br>So far, cmark and llvm compile just fine (no surprise there), and swift gets pretty far along.  The weird issue, which will certainly expose my weakness in C++ and large build systems, is that the swift_ssize_t doesn’t match ssize_t.  <br><br>[6/61] Building CXX object stdlib/public/stubs/CMakeFiles/swiftStdlibStubs-linux-armv7.dir/Stubs.cpp.o<br>FAILED: /usr/bin/clang++   -DGTEST_HAS_RTTI=0 -D_DEBUG -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -fno-stack-protector -fPIC -fvisibility-inlines-hidden -Wall -W -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wmissing-field-initializers -Wcovered-switch-default -Wnon-virtual-dtor -Werror=date-time -std=c++11 -fcolor-diagnostics -ffunction-sections -fdata-sections -Wdocumentation -Wimplicit-fallthrough -Wunreachable-code -Woverloaded-virtual -O3  -Istdlib/public/stubs -I/home/wdillon/swift/stdlib/public/stubs -I/home/wdillon/swift/include -Iinclude -I/home/wdillon/build/Ninja-ReleaseAssert/llvm-linux-armv7/include -I/home/wdillon/llvm/include -I/home/wdillon/build/Ninja-ReleaseAssert/llvm-linux-armv7/tools/clang/include -I/home/wdillon/llvm/tools/clang/include -I/home/wdillon/cmark/src -I/home/wdillon/build/Ninja-ReleaseAssert/cmark-linux-armv7/src    -UNDEBUG  -fno-exceptions -fno-rtti  -Wglobal-constructors -Wexit-time-destructors -target arm-unknown-linux-gnueabihf -isysroot / -O2 -g0 -UNDEBUG -MMD -MT stdlib/public/stubs/CMakeFiles/swiftStdlibStubs-linux-armv7.dir/LibcShims.cpp.o -MF &quot;stdlib/public/stubs/CMakeFiles/swiftStdlibStubs-linux-armv7.dir/LibcShims.cpp.o.d&quot; -o stdlib/public/stubs/CMakeFiles/swiftStdlibStubs-linux-armv7.dir/LibcShims.cpp.o -c /home/wdillon/swift/stdlib/public/stubs/LibcShims.cpp<br>/home/wdillon/swift/stdlib/public/stubs/LibcShims.cpp:24:1: error: static_assert failed &quot;__swift_ssize_t is wrong&quot;<br>static_assert(std::is_same&lt;ssize_t, swift::__swift_ssize_t&gt;::value,<br>^             ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~<br>1 error generated.<br><br>Now, the sizes match (4 bytes each), but the std::is_same() function says no.  I grep’d the clang codebase for the definition of ssize_t, and it seems like it’s a ‘long’ whereas the swift_ssize_t is a &#39;long int’.</div></blockquote><div><br></div><div>&#39;long&#39; and &#39;long int&#39; are the same type.</div><div><br></div><div>Try preprocessing the following program with &#39;clang -E&#39; and check how the type is defined:</div><div><br></div><div><div>#include &lt;unistd.h&gt;</div><div>#include &lt;sys/types.h&gt;</div></div><div> </div><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">I looked into the LibcShims a bit, and the expectation is that the definition in the header is not universally correct, and will be checked:<br><br>// This declaration is not universally correct.  We verify its correctness for<br>// the current platform in the runtime code.<br>typedef long int __swift_ssize_t;<br><br>And it is thusly (in LibcShims.cpp):<br><br>static_assert(std::is_same&lt;ssize_t, swift::__swift_ssize_t&gt;::value, &quot;__swift_ssize_t is wrong”);<br><br>What’s less clear is the mechanism with which I am to change this definition in a way that doesn’t mess-up other platforms.<br></div><div style="word-wrap:break-word"><br></div></blockquote><div><br></div><div>Use #if:</div><div><br></div><div>#if defined(__linux__) &amp;&amp; defined(__arm__)</div><div>...</div><div>#else</div><div>...</div><div>#endif </div></div><div class="gmail_extra"><br></div><div class="gmail_extra">To find the specific macro names to check for, dump the predefines buffer and find an appropriate one (although I think __linux__ and __arm__ are correct):</div><div class="gmail_extra"><br></div><div class="gmail_extra">echo &quot;&quot; | clang -x c++ -std=c++11 - -dM -E<br></div><div class="gmail_extra"><br></div>Dmitri<br clear="all"><div><br></div>-- <br><div class="gmail_signature">main(i,j){for(i=2;;i++){for(j=2;j&lt;i;j++){if(!(i%j)){j=0;break;}}if<br>(j){printf(&quot;%d\n&quot;,i);}}} /*Dmitri Gribenko &lt;<a href="mailto:gribozavr@gmail.com" target="_blank">gribozavr@gmail.com</a>&gt;*/</div>
</div></div>