[swift-dev] Building Foundation on FreeBSD
Davide Italiano
dccitaliano at gmail.com
Mon Jan 4 19:01:51 CST 2016
On Mon, Jan 4, 2016 at 4:57 PM, Davide Italiano <dccitaliano at gmail.com> wrote:
> On Mon, Dec 21, 2015 at 6:12 PM, Jordan Rose <jordan_rose at apple.com> wrote:
>>
>>> On Dec 20, 2015, at 4:14 , Davide Italiano <dccitaliano at gmail.com> wrote:
>>>
>>> On Sun, Dec 20, 2015 at 5:07 AM, Davide Italiano <dccitaliano at gmail.com> wrote:
>>>> On Sat, Dec 19, 2015 at 11:28 PM, Jordan Rose <jordan_rose at apple.com> wrote:
>>>>>
>>>>> On Dec 19, 2015, at 7:14 , Davide Italiano <dccitaliano at gmail.com> wrote:
>>>>>
>>>>> On Fri, Dec 18, 2015 at 7:58 AM, Davide Italiano <dccitaliano at gmail.com>
>>>>> wrote:
>>>>>
>>>>> On Wed, Dec 16, 2015 at 2:25 PM, Jordan Rose <jordan_rose at apple.com> wrote:
>>>>>
>>>>>
>>>>> On Dec 16, 2015, at 11:21 , Davide Italiano <dccitaliano at gmail.com> wrote:
>>>>>
>>>>> On Wed, Dec 16, 2015 at 11:17 AM, Jordan Rose <jordan_rose at 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
More information about the swift-dev
mailing list