<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Hi all,<br class=""><br class="">I’ve been working on trying to get Swift to compile on ARMv7 (armv7l specifically, not sure if other variants will work as well). &nbsp;I’ve gotten pretty far, but I ran a cross an issue that has me a little confused. &nbsp;For convenience, here’s the bug that has some of my messages in the comments:&nbsp;<a href="https://bugs.swift.org/browse/SR-40" class="">https://bugs.swift.org/browse/SR-40</a>&nbsp;and here’s my Github fork if you want to play along at home:&nbsp;<a href="https://github.com/hpux735/swift" class="">https://github.com/hpux735/swift</a>&nbsp;&nbsp;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. &nbsp;This brings native compile times down to reasonable levels. &nbsp;I was compiling on the BeagleBone Black formerly, and that was painful (like over a day for LLVM).<br class=""><br class="">So far, cmark and llvm compile just fine (no surprise there), and swift gets pretty far along. &nbsp;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. &nbsp;<br class=""><br class="">[6/61] Building CXX object stdlib/public/stubs/CMakeFiles/swiftStdlibStubs-linux-armv7.dir/Stubs.cpp.o<br class="">FAILED: /usr/bin/clang++ &nbsp;&nbsp;-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 &nbsp;-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 &nbsp;&nbsp;&nbsp;-UNDEBUG &nbsp;-fno-exceptions -fno-rtti &nbsp;-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 "stdlib/public/stubs/CMakeFiles/swiftStdlibStubs-linux-armv7.dir/LibcShims.cpp.o.d" -o stdlib/public/stubs/CMakeFiles/swiftStdlibStubs-linux-armv7.dir/LibcShims.cpp.o -c /home/wdillon/swift/stdlib/public/stubs/LibcShims.cpp<br class="">/home/wdillon/swift/stdlib/public/stubs/LibcShims.cpp:24:1: error: static_assert failed "__swift_ssize_t is wrong"<br class="">static_assert(std::is_same&lt;ssize_t, swift::__swift_ssize_t&gt;::value,<br class="">^ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~<br class="">1 error generated.<br class=""><br class="">Now, the sizes match (4 bytes each), but the std::is_same() function says no. &nbsp;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 'long int’. &nbsp;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 class=""><br class="">// This declaration is not universally correct. &nbsp;We verify its correctness for<br class="">// the current platform in the runtime code.<br class="">typedef long int __swift_ssize_t;<br class=""><br class="">And it is thusly (in LibcShims.cpp):<br class=""><br class="">static_assert(std::is_same&lt;ssize_t, swift::__swift_ssize_t&gt;::value, "__swift_ssize_t is wrong”);<br class=""><br class="">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 class=""><br class="">Any thoughts and ideas are welcome!<br class="">Cheers,<br class="">- Will</body></html>