Just to update the record, Matthias M. Schneider posted a workaround on bugs.swift.org.
By setting the C_INCLUDE_PATH and CPLUS_INCLUDE_PATH environment variables to point to the Clang headers directory, it is possible to both import Foundation in the REPL (without using -I to pass the header include path) and also to debug a built executable with lldb. Example is on the bug tracker: https://bugs.swift.org/browse/SR-3648?focusedCommentId=27131&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-27131 Cheers, — Mason > On Jul 12, 2017, at 13:16, Mason Mark via swift-users <swift-users@swift.org> > wrote: > > 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 _______________________________________________ swift-users mailing list swift-users@swift.org https://lists.swift.org/mailman/listinfo/swift-users
