On Mon, Jan 4, 2016 at 4:57 PM, Davide Italiano <dccitali...@gmail.com> wrote: > On Mon, Dec 21, 2015 at 6:12 PM, Jordan Rose <jordan_r...@apple.com> wrote: >> >>> 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 > > That did the trick -- but only for include paths problems (I now get > similar errors at linking time). > Is there any other env variable or argument I need to pass -- which I'm > missing? > > /exps/swift/build/Ninja-ReleaseAssert/swift-freebsd-x86_64/lib/swift/freebsd/libswiftStdlibUnittest.so: > undefined reference to `pthread_create' > /exps/swift/build/Ninja-ReleaseAssert/swift-freebsd-x86_64/lib/swift/freebsd/libswiftStdlibUnittest.so: > undefined reference to `freebsdGetEnviron' > /exps/swift/build/Ninja-ReleaseAssert/swift-freebsd-x86_64/lib/swift/freebsd/libswiftStdlibUnittest.so: > undefined reference to `_TF5Glibcg5errnoVs5Int32' > /exps/swift/build/Ninja-ReleaseAssert/swift-freebsd-x86_64/lib/swift/freebsd/libswiftStdlibUnittest.so: > undefined reference to `_TF5Glibcs5errnoVs5Int32' > /exps/swift/build/Ninja-ReleaseAssert/swift-freebsd-x86_64/lib/swift/freebsd/libswiftStdlibUnittest.so: > undefined reference to `_swift_FORCE_LOAD_$_swiftGlibc' > > > Thanks! > > -- > Davide
This is how the compiler is invoked, for correctness: % /exps/swift/swift/test/1_stdlib/../../utils/line-directive /exps/swift/build/Ninja-ReleaseAssert/swift-freebsd-x86_64/test-freebsd-x86_64/1_stdlib/Output/Index.swift.gyb.tmp/Index.swift -- /exps/swift/build/Ninja-ReleaseAssert/swift-freebsd-x86_64/bin/swiftc -target x86_64-unknown-freebsd11.0-CURRENT -module-cache-path '/tmp/swift-testsuite-clang-module-cacheU1oeNQ' /exps/swift/build/Ninja-ReleaseAssert/swift-freebsd-x86_64/test-freebsd-x86_64/1_stdlib/Output/Index.swift.gyb.tmp/Index.swift -sdk / -o /exps/swift/build/Ninja-ReleaseAssert/swift-freebsd-x86_64/test-freebsd-x86_64/1_stdlib/Output/Index.swift.gyb.tmp/a.out It seems -lpthread (and others) aren't passed around -- shouldn't lib/Driver take care of that by default? Thanks, -- Davide _______________________________________________ swift-dev mailing list swift-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-dev
