For the mail (so it's easier to find than in a bug tracking system) the fix is to specify the clang include headers either with an -I on the swift invocation command line, or via the variables C_INCLUDE_PATH and CPLUS_INCLUDE_PATH
setting the C_INCLUDE_PATH and CPLUS_INCLUDE_PATH environment variables to the Clang header include path did indeed work $ export C_INCLUDE_PATH=/swift/usr/lib/swift/clang/include/ $ export CPLUS_INCLUDE_PATH=$C_INCLUDE_PATH $ $ swift Welcome to Swift version 4.0-dev (LLVM a15decabe3, Clang 14ff3d9712, Swift d574ed67d6). Type :help for assistance. 1> import Foundation 2> let status = "woohoo! 'import Foundation' works on Linux" status: String = "woohoo! \'import Foundation\' works on Linux" It really shouldn't be necessary to have to specify additional flags or variables to have Swift's REPL work out of the box on Linux, like it used to with Swift 3.0. Alex > On 26 Jul 2017, at 05:17, Mason Mark via swift-users <swift-users@swift.org> > wrote: > > Just to update the record, Matthias M. Schneider posted a workaround on > bugs.swift.org <http://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 > > <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 >> <mailto: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 <mailto:swift-users@swift.org> >> https://lists.swift.org/mailman/listinfo/swift-users >> <https://lists.swift.org/mailman/listinfo/swift-users> > > _______________________________________________ > swift-users mailing list > swift-users@swift.org <mailto:swift-users@swift.org> > https://lists.swift.org/mailman/listinfo/swift-users > <https://lists.swift.org/mailman/listinfo/swift-users>
_______________________________________________ swift-users mailing list swift-users@swift.org https://lists.swift.org/mailman/listinfo/swift-users
