<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=""><div class="">Hi, Davide. On OS X, there are no headers in /, so it's pretty important that Swift doesn't try to use what's in /. (This was doubly true during the transition period where many people had <i class="">stale</i> headers in /.) It's also common to use swiftc to cross-compile on OS X, and we didn't want inscrutable errors about using OS X headers while compiling for iOS.</div><div class=""><br class=""></div><div class="">That said, on OS X either Xcode or the "xcrun" tool takes care of setting up SDKROOT appropriately. I'd be fine with it defaulting to / on FreeBSD (and Linux), like C compilers do. If you're interested in implementing this, I would <a href="https://github.com/apple/swift/blob/master/lib/Driver/Driver.cpp#L1080" class="">put it into the Driver</a>; we already do this for "swift" (the interpreter) on OS X.</div><div class=""><br class=""></div><div class="">The test suite deliberately blocks out <i class="">all</i> environment variables from your environment except for a select few, to minimize the chance that something is passing (or failing!) based solely on your configuration. For the test suite specifically, I would suggest adding "-sdk" to the %target-swift-frontend substitution the way we do on OS X.</div><div class=""><br class=""></div><div class="">Best,</div><div class="">Jordan</div><br class=""><div><blockquote type="cite" class=""><div class="">On Jan 8, 2016, at 15:12, Davide Italiano <<a href="mailto:dccitaliano@gmail.com" class="">dccitaliano@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">Hi.<br class="">I've eventually tracked down all the problems that prevented swift<br class="">standard library and related tests to run correctly under FreeBSD but<br class="">one.When I run the testsuite as ./utils/build-script -R -t each single<br class="">test requiring SwiftGlibc fails because of missing headers.<br class="">e.g.<br class=""><br class=""><module-includes>:1:10: note: in file included from <module-includes>:1:<br class="">#include "/usr/include/complex.h"<br class=""> ^<br class="">/usr/include/complex.h:32:10: error: 'sys/cdefs.h' file not found with<br class=""><angled> include; use "quotes" instead<br class="">#include <sys/cdefs.h><br class=""> ^<br class=""><module-includes>:2:10: note: in file included from <module-includes>:2:<br class="">#include "/usr/include/ctype.h"<br class=""> ^<br class=""><br class="">In a different thread Jordan suggested to pass -sdk / to see if that<br class="">fixed the problem, and indeed it did. Digging into the code I noticed<br class="">that the Driver checks for SDKROOT environment variable being set as<br class="">fallback if -sdk argument isn't passed on the cmdline.<br class=""><br class="">If I set that environment variable and I run the tests standalone<br class="">(directly from cmdline), everything seems to be fine.<br class=""><br class="">% /exps/swift/build/Ninja-ReleaseAssert/swift-freebsd-x86_64/bin/swiftc<br class="">-target x86_64-unknown-freebsd11.0-CURRENT -module-cache-path<br class="">'/tmp/swift-testsuite-clang-module-cache3VHSof'<br class="">/exps/swift/swift/test/1_stdlib/Builtins.swift -parse-stdlib<br class="">-Xfrontend -disable-access-control -Onone -o<br class="">/exps/swift/build/Ninja-ReleaseAssert/swift-freebsd-x86_64/test-freebsd-x86_64/1_stdlib/Output/Builtins.swift.tmp/Builtins<br class="">/exps/swift/swift/test/1_stdlib/Builtins.swift:113:3: warning: result<br class="">of call to 'unsafeUnwrap' is unused<br class=""> unsafeUnwrap(empty)<br class=""> ^<br class="">davide@rabbit1:/exps/swift/swift % echo $SDKROOT<br class="">/<br class=""><br class="">But, if I run the whole testsuite, it fails (with the error above).<br class="">I'm no expert about swift build but it seems to me SDKROOT isn't<br class="">honored when the testsuite is invoked (maybe it doesn't share the<br class="">enviroment with the calling process?)<br class=""><br class="">In any case, I'm interested in getting this fixed as it seems to be<br class="">the only missing bit to get the whole testsuite to run (and setup a<br class="">buildbot to catch regressions).<br class=""><br class="">I'm not sure if it's better forcing the user to pass SDKROOT (and then<br class="">understanding why it's not honoured), or forcing -sdk / to be passed<br class="">to each test. I'm not sure what Linux does (and wasn't entirely<br class="">obvious to me where to look).<br class="">Any suggestion on how to handle this case is greatly appreciated.<br class=""><br class="">Thanks,<br class=""><br class="">--<br class="">Davide<br class=""></div></div></blockquote></div><br class=""></body></html>