[swift-dev] Building Foundation on FreeBSD

[Jordan Rose]

> 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