Swift linux repl can't import

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?

···

--
Rick Mann
rmann@latencyzero.com

From [SR-3648] Unable to Import Foundation · Issue #46233 · apple/swift · GitHub, 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?

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]: [SR-3648] Unable to Import Foundation · Issue #46233 · apple/swift · GitHub

···

On Apr 5, 2017, at 11:53, Will Stanton via swift-users <swift-users@swift.org> wrote:

From [SR-3648] Unable to Import Foundation · Issue #46233 · apple/swift · GitHub, 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

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:

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]: [SR-3648] Unable to Import Foundation · Issue #46233 · apple/swift · GitHub

On Apr 5, 2017, at 11:53, Will Stanton via swift-users <swift-users@swift.org> wrote:

From [SR-3648] Unable to Import Foundation · Issue #46233 · apple/swift · GitHub, 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

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 <Issues · apple/swift · GitHub.

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:

[SR-3648] Unable to Import Foundation · Issue #46233 · apple/swift · GitHub <[SR-3648] Unable to Import Foundation · Issue #46233 · apple/swift · GitHub;

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]: [SR-3648] Unable to Import Foundation · Issue #46233 · apple/swift · GitHub

On Apr 5, 2017, at 11:53, Will Stanton via swift-users <swift-users@swift.org> wrote:

From [SR-3648] Unable to Import Foundation · Issue #46233 · apple/swift · GitHub, 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

_______________________________________________
swift-users mailing list
swift-users@swift.org <mailto:swift-users@swift.org>
https://lists.swift.org/mailman/listinfo/swift-users