From https://bugs.swift.org/browse/SR-3648, the work-around seems to be passing -I /path/to/extracted/usr/lib/swift/clang/include when invoking swift (credit Lukas and others, SR-3794 is more active) So, ex. `swift -I ~/a-swift/usr/lib/swift/clang/include/`
Fortunately, the issue has only come up for me in the REPL. `swift build` works fine: I can build packages without an awkward -Xswiftc… I wonder if the issue has anything to do with the clang-builtin-headers install component? (Maybe swiftc/something gets hardcoded with a path somewhere?) Would be interested in learning more about install options, toolchains, and the build! I’ve been wanting to track down for a while now, how does --install-prefix affect the build? I’ve been relying on install_destdir to get a swift... Regards, Will Stanton > On Apr 4, 2017, at 9:17 PM, Rick Mann via swift-users <swift-us...@swift.org> > wrote: > > The installation instructions for Swift on Linux imply that the tarball can > be extracted anywhere, and the PATH set, and all should be well. But > unfortunately, while that's partly true, when I try to import packages, it > fails (Ubuntu 16.04 on Parallels on macOS 10.12.3): > > $ swift > Welcome to Swift version 3.1 (swift-3.1-RELEASE). Type :help for assistance. > 1> 1+1 > $R0: Int = 2 > 2> import Glibc > <module-includes>:3:10: note: in file included from <module-includes>:3: > #include "///usr/include/utmp.h" > ^ > > ///usr/include/utmp.h:23:10: note: in file included from > ///usr/include/utmp.h:23: > #include <sys/types.h> > ^ > > error: /usr/include/x86_64-linux-gnu/sys/types.h:146:10: error: 'stddef.h' > file not found > #include <stddef.h> > ^ > > error: could not build Objective-C module 'SwiftGlibc' > > 2> > > I'm guessing it really wants Swift to live inside /usr? _______________________________________________ swift-dev mailing list swift-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-dev
