> On Dec 20, 2015, at 4:14 , Davide Italiano <dccitali...@gmail.com> wrote: > > On Sun, Dec 20, 2015 at 5:07 AM, Davide Italiano <dccitali...@gmail.com> > wrote: >> On Sat, Dec 19, 2015 at 11:28 PM, Jordan Rose <jordan_r...@apple.com> wrote: >>> >>> On Dec 19, 2015, at 7:14 , Davide Italiano <dccitali...@gmail.com> wrote: >>> >>> On Fri, Dec 18, 2015 at 7:58 AM, Davide Italiano <dccitali...@gmail.com> >>> wrote: >>> >>> On Wed, Dec 16, 2015 at 2:25 PM, Jordan Rose <jordan_r...@apple.com> wrote: >>> >>> >>> On Dec 16, 2015, at 11:21 , Davide Italiano <dccitali...@gmail.com> wrote: >>> >>> On Wed, Dec 16, 2015 at 11:17 AM, Jordan Rose <jordan_r...@apple.com> wrote: >>> >>> What's the compile command for the files that are failing? If the target >>> triple there doesn't include a version number, it might be defaulting to >>> something like "1.0". >>> >>> Jordan >>> >>> >>> I see many of these, here's an example: >>> http://people.freebsd.org/~davide/swift/modules_failure.txt >>> >>> BTW, the triple includes a version number (freebsd-unknown-11.0) >>> >>> >>> Ah, not the one I see: "-target x86_64-unknown-freebsd". Try adding "11.0" >>> to that. (Presumably it comes from the Foundation build script, so you might >>> have to find where it's being passed down.) >>> >>> >>> Thanks! >>> I followed your suggestion and I was able to make progress. >>> While we're at this -- I had another issue with modules (when running >>> testsuite) that I wasn't able to solve (and which causes a lot of test >>> failures because Objective-C modules can't be build), i.e. missing >>> headers. >>> >>> Command Output (stderr): >>> -- >>> <module-includes>:1:10: note: in file included from <module-includes>:1: >>> #include "/usr/include/complex.h" >>> ^ >>> /usr/include/complex.h:32:10: error: 'sys/cdefs.h' file not found with >>> <angled> include; use "quotes" instead >>> #include <sys/cdefs.h> >>> ^ >>> <module-includes>:2:10: note: in file included from <module-includes>:2: >>> #include "/usr/include/ctype.h" >>> ^ >>> /usr/include/ctype.h:44:10: error: 'sys/cdefs.h' file not found with >>> <angled> include; use "quotes" instead >>> #include <sys/cdefs.h> >>> ^ >>> [...] >>> >>> >>> I tracked this one down and realized the problem is that include paths >>> (i.e. /usr/include) aren't passed correctly to swiftc in the tests. I >>> worked around >>> this passing -I/usr/include but I'd like to fix this right for >>> FreeBSD. Where's the correct place where CXXFLAGS and LDFLAGS should >>> be passed? >>> >>> >>> Hm. The Clang inside Swift should be supplying by default just from the >>> target triple. If you pass "-Xcc -v" to swiftc it should dump the default >>> search paths for your platform. What does that look like? >>> >>> Jordan >> >> clang version 3.8.0 (https://github.com/apple/swift-clang.git >> f66c5bb67b9a1016b51d2eff0f497d4528dacc0a) >> (https://github.com/apple/swift-llvm.git >> 3ebdbb2c7e5ce577363994fd0aa0f8409bc68490) >> Target: x86_64-unknown-freebsd11.0-CURRENT >> Thread model: posix >> InstalledDir: >> #include "..." search starts here: >> #include <...> search starts here: >> /exps/swift/build/Ninja-ReleaseAssert/swift-freebsd-x86_64/lib/swift >> /exps/swift/build/Ninja-ReleaseAssert/swift-freebsd-x86_64/lib/swift/clang/include >> End of search list. >> >> hmm -- /usr/include is not there although I expect that to be a >> reasonably standard place to look for headers (at least in FreeBSD). >> Maybe the driver should grow to take this in account? What do you >> think? >> > > Just FYI, clang seems to pass the correct path for C/C++. > > $ ./clang blah.c -v > clang version 3.8.0 (trunk 256106) > Target: x86_64-unknown-freebsd11.0 > Thread model: posix > InstalledDir: /exps/llvm-lld/build/bin/. > "/exps/llvm-lld/build/bin/clang-3.8" -cc1 -triple > x86_64-unknown-freebsd11.0 -emit-obj -mrelax-all -disable-free > -main-file-name blah.c -mrelocation-model static -mthread-model posix > -mdisable-fp-elim -masm-verbose -mconstructor-aliases -munwind-tables > -target-cpu x86-64 -v -dwarf-column-info -debugger-tuning=lldb > -resource-dir /exps/llvm-lld/build/bin/../lib/clang/3.8.0 > -fdebug-compilation-dir /exps/llvm-lld/build/bin -ferror-limit 19 > -fmessage-length 197 -fobjc-runtime=gnustep -fdiagnostics-show-option > -fcolor-diagnostics -o /tmp/blah-b46104.o -x c blah.c > clang -cc1 version 3.8.0 based upon LLVM 3.8.0svn default target > x86_64-unknown-freebsd11.0 > #include "..." search starts here: > #include <...> search starts here: > /exps/llvm-lld/build/bin/../lib/clang/3.8.0/include > /usr/include > > $ cat blah.c > #include <sys/types.h> > > int > main(void) > { > return (0); > }
Ah, as an experiment can you try passing "-sdk /"? That's supposed to be the default on a non-Darwin system, but maybe it's a positive test for Linux instead of a negative test for "Apple-like platforms". Jordan _______________________________________________ swift-dev mailing list swift-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-dev
