[swift-dev] Building Foundation on FreeBSD

Davide Italiano dccitaliano at gmail.com
Mon Jan 4 18:57:13 CST 2016


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


More information about the swift-dev mailing list