I'm reviving this somewhat-old thread because it's still the most prominent search result when googling this issue to debug it (other than the below-referenced SR-3648).
The workaround of using -I to pass an include path to swift was working for me, because as noted by Will Stanton below, the issue was only coming up when trying to use the REPL on Linux (builds aren't affected). However, the same issue comes up when debugging a swift executable on Linux using lldb, which I now need to do. So I'd love to know if anybody has found a workaround. When you try to "po foo" in lldb, assuming foo is some object that uses Foundation, lldb errors out with a cascade of #include errors, ultimately ending with the same "error: 'stddef.h' file not found" (just like the REPL does). I posted a comment to the official bug thread[1] which includes the full lldb output. My reason for posting to the list here is mainly to see if somebody has figured out a workaround, e.g.: - Does installing swift and all its stuff in /usr/lib help? - Is there some way to get lldb to do the equivalent of `swift -I ~/a-swift/usr/lib/swift/clang/include/`? - Are there any versions of Linux where this issue does not occur? (Occurs for me with both Swift 3 and 4-dev, on Ubuntu 16.04.) - etc. Thanks for any pointers or tips. Unlike with the REPL case and its workaround, for trying to debug Swift executables on Linux this seems to be a show-stopper for me. — Mason [1]: https://bugs.swift.org/browse/SR-3648 > On Apr 5, 2017, at 11:53, Will Stanton via swift-users > <swift-users@swift.org> wrote: > > 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-users@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-users mailing list > swift-users@swift.org > https://lists.swift.org/mailman/listinfo/swift-users _______________________________________________ swift-users mailing list swift-users@swift.org https://lists.swift.org/mailman/listinfo/swift-users
