Building Foundation on FreeBSD

Development Compiler
1

Hi,
I'm in the process of porting Foundation to FreeBSD (see
https://github.com/apple/swift-corelibs-foundation/pull/141\).
After fixing a bunch of build/portability errors I'm now stuck trying
to fix an issue with modules.
In particular, I see a lot of errors like this:

<unknown>:0: error: module file's minimum deployment target is
freebsd11.0 v11.0:
/exps/swift/build/Ninja-ReleaseAssert/swift-freebsd-x86_64/lib/swift/freebsd/x86_64/Swift.swiftmodule

The version seems to match
$ uname -s -r
FreeBSD 11.0-CURRENT

I tried to google to get help but all I find are ways to solve this in
XCode. I also tried to navigate the sources to find a culprit but I
failed in doing that. Is there any easy way to get this working? Or at
least, to ignore the deployment target version check for now (as a
workaround) in order to make progress?

Thanks,

···

--
Davide

2

+Jordan for module issues.

···

On Tue, Dec 15, 2015 at 10:55 AM, Davide Italiano via swift-dev <swift-dev@swift.org> wrote:

Hi,
I'm in the process of porting Foundation to FreeBSD (see
https://github.com/apple/swift-corelibs-foundation/pull/141\).
After fixing a bunch of build/portability errors I'm now stuck trying
to fix an issue with modules.
In particular, I see a lot of errors like this:

<unknown>:0: error: module file's minimum deployment target is
freebsd11.0 v11.0:
/exps/swift/build/Ninja-ReleaseAssert/swift-freebsd-x86_64/lib/swift/freebsd/x86_64/Swift.swiftmodule

The version seems to match
$ uname -s -r
FreeBSD 11.0-CURRENT

I tried to google to get help but all I find are ways to solve this in
XCode. I also tried to navigate the sources to find a culprit but I
failed in doing that. Is there any easy way to get this working? Or at
least, to ignore the deployment target version check for now (as a
workaround) in order to make progress?

Thanks,

--
Davide
_______________________________________________
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

--
main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
(j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr@gmail.com>*/

3

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

···

On Dec 15, 2015, at 10:55 , Davide Italiano via swift-dev <swift-dev@swift.org> wrote:

Hi,
I'm in the process of porting Foundation to FreeBSD (see
https://github.com/apple/swift-corelibs-foundation/pull/141\).
After fixing a bunch of build/portability errors I'm now stuck trying
to fix an issue with modules.
In particular, I see a lot of errors like this:

<unknown>:0: error: module file's minimum deployment target is
freebsd11.0 v11.0:
/exps/swift/build/Ninja-ReleaseAssert/swift-freebsd-x86_64/lib/swift/freebsd/x86_64/Swift.swiftmodule

The version seems to match
$ uname -s -r
FreeBSD 11.0-CURRENT

I tried to google to get help but all I find are ways to solve this in
XCode. I also tried to navigate the sources to find a culprit but I
failed in doing that. Is there any easy way to get this working? Or at
least, to ignore the deployment target version check for now (as a
workaround) in order to make progress?

Thanks,

--
Davide
_______________________________________________
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

4

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)

Thanks,

···

On Wed, Dec 16, 2015 at 11:17 AM, Jordan Rose <jordan_rose@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

--
Davide

5

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.)

Jordan

···

On Dec 16, 2015, at 11:21 , Davide Italiano <dccitaliano@gmail.com> wrote:

On Wed, Dec 16, 2015 at 11:17 AM, Jordan Rose <jordan_rose@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)

6

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):

···

On Wed, Dec 16, 2015 at 2:25 PM, Jordan Rose <jordan_rose@apple.com> wrote:

On Dec 16, 2015, at 11:21 , Davide Italiano <dccitaliano@gmail.com> wrote:

On Wed, Dec 16, 2015 at 11:17 AM, Jordan Rose <jordan_rose@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.)

--
<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 patched the module map to add those headers, i.e.:

+ module cdefs {
+ header "@GLIBC_ARCH_INCLUDE_PATH@/sys/cdefs.h"
+ export *
+ }
+ module _types {
+ header "@GLIBC_ARCH_INCLUDE_PATH@/sys/_types.h"
+ export *
+ }

but it seems they're not still picked correctly. I also tried to change
<> into "" but, no luck (I also very dislike this approach because I think
system headers shouldn't be modified to get this to work). Any
ideas on what can be wrong/I'm missing?

Thanks,

--
Davide

7

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?

Thanks,

···

On Fri, Dec 18, 2015 at 7:58 AM, Davide Italiano <dccitaliano@gmail.com> wrote:

On Wed, Dec 16, 2015 at 2:25 PM, Jordan Rose <jordan_rose@apple.com> wrote:

On Dec 16, 2015, at 11:21 , Davide Italiano <dccitaliano@gmail.com> wrote:

On Wed, Dec 16, 2015 at 11:17 AM, Jordan Rose <jordan_rose@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>
         ^
[...]

--
Davide

8

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

···

On Dec 19, 2015, at 7:14 , Davide Italiano <dccitaliano@gmail.com> wrote:

On Fri, Dec 18, 2015 at 7:58 AM, Davide Italiano <dccitaliano@gmail.com <mailto:dccitaliano@gmail.com>> wrote:

On Wed, Dec 16, 2015 at 2:25 PM, Jordan Rose <jordan_rose@apple.com> wrote:

On Dec 16, 2015, at 11:21 , Davide Italiano <dccitaliano@gmail.com> wrote:

On Wed, Dec 16, 2015 at 11:17 AM, Jordan Rose <jordan_rose@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?

9

clang version 3.8.0 (GitHub - apple/swift-clang
f66c5bb67b9a1016b51d2eff0f497d4528dacc0a)
(GitHub - apple/swift-llvm
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?

Thanks!

···

On Sat, Dec 19, 2015 at 11:28 PM, Jordan Rose <jordan_rose@apple.com> wrote:

On Dec 19, 2015, at 7:14 , Davide Italiano <dccitaliano@gmail.com> wrote:

On Fri, Dec 18, 2015 at 7:58 AM, Davide Italiano <dccitaliano@gmail.com> > wrote:

On Wed, Dec 16, 2015 at 2:25 PM, Jordan Rose <jordan_rose@apple.com> wrote:

On Dec 16, 2015, at 11:21 , Davide Italiano <dccitaliano@gmail.com> wrote:

On Wed, Dec 16, 2015 at 11:17 AM, Jordan Rose <jordan_rose@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

--
Davide

10

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);
}

···

On Sun, Dec 20, 2015 at 5:07 AM, Davide Italiano <dccitaliano@gmail.com> wrote:

On Sat, Dec 19, 2015 at 11:28 PM, Jordan Rose <jordan_rose@apple.com> wrote:

On Dec 19, 2015, at 7:14 , Davide Italiano <dccitaliano@gmail.com> wrote:

On Fri, Dec 18, 2015 at 7:58 AM, Davide Italiano <dccitaliano@gmail.com> >> wrote:

On Wed, Dec 16, 2015 at 2:25 PM, Jordan Rose <jordan_rose@apple.com> wrote:

On Dec 16, 2015, at 11:21 , Davide Italiano <dccitaliano@gmail.com> wrote:

On Wed, Dec 16, 2015 at 11:17 AM, Jordan Rose <jordan_rose@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 (GitHub - apple/swift-clang
f66c5bb67b9a1016b51d2eff0f497d4528dacc0a)
(GitHub - apple/swift-llvm
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?

11

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

···

On Dec 20, 2015, at 4:14 , Davide Italiano <dccitaliano@gmail.com> wrote:

On Sun, Dec 20, 2015 at 5:07 AM, Davide Italiano <dccitaliano@gmail.com> wrote:

On Sat, Dec 19, 2015 at 11:28 PM, Jordan Rose <jordan_rose@apple.com> wrote:

On Dec 19, 2015, at 7:14 , Davide Italiano <dccitaliano@gmail.com> wrote:

On Fri, Dec 18, 2015 at 7:58 AM, Davide Italiano <dccitaliano@gmail.com> >>> wrote:

On Wed, Dec 16, 2015 at 2:25 PM, Jordan Rose <jordan_rose@apple.com> wrote:

On Dec 16, 2015, at 11:21 , Davide Italiano <dccitaliano@gmail.com> wrote:

On Wed, Dec 16, 2015 at 11:17 AM, Jordan Rose <jordan_rose@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 (GitHub - apple/swift-clang
f66c5bb67b9a1016b51d2eff0f497d4528dacc0a)
(GitHub - apple/swift-llvm
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);
}

12

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!

···

On Mon, Dec 21, 2015 at 6:12 PM, Jordan Rose <jordan_rose@apple.com> wrote:

On Dec 20, 2015, at 4:14 , Davide Italiano <dccitaliano@gmail.com> wrote:

On Sun, Dec 20, 2015 at 5:07 AM, Davide Italiano <dccitaliano@gmail.com> wrote:

On Sat, Dec 19, 2015 at 11:28 PM, Jordan Rose <jordan_rose@apple.com> wrote:

On Dec 19, 2015, at 7:14 , Davide Italiano <dccitaliano@gmail.com> wrote:

On Fri, Dec 18, 2015 at 7:58 AM, Davide Italiano <dccitaliano@gmail.com> >>>> wrote:

On Wed, Dec 16, 2015 at 2:25 PM, Jordan Rose <jordan_rose@apple.com> wrote:

On Dec 16, 2015, at 11:21 , Davide Italiano <dccitaliano@gmail.com> wrote:

On Wed, Dec 16, 2015 at 11:17 AM, Jordan Rose <jordan_rose@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 (GitHub - apple/swift-clang
f66c5bb67b9a1016b51d2eff0f497d4528dacc0a)
(GitHub - apple/swift-llvm
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

--
Davide

13

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,

···

On Mon, Jan 4, 2016 at 4:57 PM, Davide Italiano <dccitaliano@gmail.com> wrote:

On Mon, Dec 21, 2015 at 6:12 PM, Jordan Rose <jordan_rose@apple.com> wrote:

On Dec 20, 2015, at 4:14 , Davide Italiano <dccitaliano@gmail.com> wrote:

On Sun, Dec 20, 2015 at 5:07 AM, Davide Italiano <dccitaliano@gmail.com> wrote:

On Sat, Dec 19, 2015 at 11:28 PM, Jordan Rose <jordan_rose@apple.com> wrote:

On Dec 19, 2015, at 7:14 , Davide Italiano <dccitaliano@gmail.com> wrote:

On Fri, Dec 18, 2015 at 7:58 AM, Davide Italiano <dccitaliano@gmail.com> >>>>> wrote:

On Wed, Dec 16, 2015 at 2:25 PM, Jordan Rose <jordan_rose@apple.com> wrote:

On Dec 16, 2015, at 11:21 , Davide Italiano <dccitaliano@gmail.com> wrote:

On Wed, Dec 16, 2015 at 11:17 AM, Jordan Rose <jordan_rose@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 (GitHub - apple/swift-clang
f66c5bb67b9a1016b51d2eff0f497d4528dacc0a)
(GitHub - apple/swift-llvm
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

--
Davide