Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[SR-3648] Unable to Import Foundation #46233

Open
swift-ci opened this issue Jan 16, 2017 · 11 comments
Open

[SR-3648] Unable to Import Foundation #46233

swift-ci opened this issue Jan 16, 2017 · 11 comments
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. compiler The Swift compiler in itself

Comments

@swift-ci
Copy link
Collaborator

Previous ID SR-3648
Radar None
Original Reporter Deltalus (JIRA User)
Type Bug
Environment

Ubuntu 16.10 Swift version 3.1-dev (LLVM 7e421db87c, Clang 4a0ed6aa35, Swift 5a24741)

Additional Detail from JIRA
Votes 10
Component/s Compiler
Labels Bug
Assignee None
Priority Medium

md5: b658a942de2da11f0d869a04c5e065be

is duplicated by:

  • SR-5686 Swift 4 REPL broken on Linux (Docker)

relates to:

  • SR-3658 Can't build CoreFoundation on Ubuntu 16.04, January 16
  • SR-3794 import Glibc does not work from the swift 3.1-dev REPL
  • SR-5524 Importing a modulemapped C library in REPL throws an error

Issue Description:

I am unable to use Foundation as it sparks an error when trying to find its own files.

$HOME/swift-DEVELOPMENT-SNAPSHOT-2017-01-14-a-ubuntu16.10/usr/lib/swift/CoreFoundation/CoreFoundation.h:25:10: note: while building module 'SwiftGlibc' imported from $HOME/swift-DEVELOPMENT-SNAPSHOT-2017-01-14-a-ubuntu16.10/usr/lib/swift/CoreFoundation/CoreFoundation.h:25:
#include <sys/types.h>
         ^

<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>
         ^

<module-includes>:1:10: note: in file included from <module-includes>:1:
#include "CoreFoundation.h"
         ^

error: $HOME/swift-DEVELOPMENT-SNAPSHOT-2017-01-14-a-ubuntu16.10/usr/lib/swift/CoreFoundation/CoreFoundation.h:25:10: error: could not build module 'SwiftGlibc'
#include <sys/types.h>
         ^

$HOME/swift-DEVELOPMENT-SNAPSHOT-2017-01-14-a-ubuntu16.10/usr/lib/swift/CoreFoundation/CFStream.h:20:10: note: while building module 'CDispatch' imported from $HOME/swift-DEVELOPMENT-SNAPSHOT-2017-01-14-a-ubuntu16.10/usr/lib/swift/CoreFoundation/CFStream.h:20:
#include <dispatch/dispatch.h>
         ^

<module-includes>:1:10: note: in file included from <module-includes>:1:
#include "dispatch.h"
         ^

$HOME/swift-DEVELOPMENT-SNAPSHOT-2017-01-14-a-ubuntu16.10/usr/lib/swift/dispatch/dispatch.h:41:10: note: in file included from $HOME/swift-DEVELOPMENT-SNAPSHOT-2017-01-14-a-ubuntu16.10/usr/lib/swift/dispatch/dispatch.h:41:
#include <sys/cdefs.h>
         ^

error: /usr/include/x86_64-linux-gnu/sys/cdefs.h:23:11: error: could not build module 'SwiftGlibc'
# include <features.h>
          ^

error: could not build Objective-C module 'CoreFoundation'
@belkadan
Copy link
Contributor

Missing stddef.h implies that we couldn't find the Clang headers relative to Swift (they should be in lib/swift/clang/). @shahmishal, have we heard about this before?

@swift-ci
Copy link
Collaborator Author

Comment by Mason Mark (JIRA)

I think this issue is related to, or possibly a duplicate of, SR-3794.

On Ubuntu 10.4, I saw identical symptoms as described in this issue. But the workaround described on the other issue, of manually supplying the include path as a command-line argument when launching the swift REPL, made it work normally:

BEFORE: REPL malfunctions when I try to import Foundation

ubuntu@mason-linux-2017:~$ swift
Welcome to Swift version 3.1-dev (LLVM a7c680da51, Clang f186e73135, Swift 41ac6d6991). Type :help for assistance.
  1> import Foundation
<module-includes>:1:10: note: in file included from <module-includes>:1:
#include "CoreFoundation.h"
         ^

error: /swift-3.1-DEVELOPMENT-SNAPSHOT-2017-02-11-a-ubuntu16.04/usr/lib/swift/CoreFoundation/CoreFoundation.h:26:10: error: 'stdarg.h' file not found
#include <stdarg.h>
         ^

/swift-3.1-DEVELOPMENT-SNAPSHOT-2017-02-11-a-ubuntu16.04/usr/lib/swift/CoreFoundation/CFStream.h:20:10: note: while building module 'CDispatch' imported from /swift-3.1-DEVELOPMENT-SNAPSHOT-2017-02-11-a-ubuntu16.04/usr/lib/swift/CoreFoundation/CFStream.h:20:
#include <dispatch/dispatch.h>
         ^

<module-includes>:1:10: note: in file included from <module-includes>:1:
#include "dispatch.h"
         ^

error: /swift-3.1-DEVELOPMENT-SNAPSHOT-2017-02-11-a-ubuntu16.04/usr/lib/swift/dispatch/dispatch.h:43:10: error: 'stddef.h' file not found
#include <stddef.h>
         ^

error: could not build Objective-C module 'CoreFoundation'

  1> let foo = URL(string: "http://example.com")
Shared Swift state for repl_swift has developed fatal errors and is being discarded.
REPL definitions and persistent names/types will be lost.
error: repl.swift:1:11: error: use of unresolved identifier 'URL'
let foo = URL(string: "http://example.com")
          ^~~


  1>  

AFTER: REPL works when I supply include path as command line argument when launching swift:

ubuntu@mason-linux-2017:~$ swift -I/swift/usr/lib/swift/clang/include/
Welcome to Swift version 3.1-dev (LLVM a7c680da51, Clang f186e73135, Swift 41ac6d6991). Type :help for assistance.
  1> import Foundation
  2> let foo = URL(string: "http://example.com")
foo: Foundation.URL? = some {...}

Note: path used may vary based on where swift is installed; on this machine latest swift snapshot is installed at /swift.

@swift-ci
Copy link
Collaborator Author

Comment by Mason Mark (JIRA)

Same workaround fixes; may actually be duplicate.

@swift-ci
Copy link
Collaborator Author

swift-ci commented Apr 5, 2017

Comment by Rick M (JIRA)

This was affecting me on Ubuntu 16.04, importing anything (Glibc, etc), in the swift repl. It does not seem to affect switfc

@swift-ci
Copy link
Collaborator Author

Comment by Mason Mark (JIRA)

The workaround above works for the REPL case:

swift -I/swift/usr/lib/swift/clang/include/

However, the same basic issue is present when trying to debug a Swift executable on Linux using lldb. Inside lldb, the same crash is occurring when trying to print an object that uses Foundation. Is there any way to do the equivalent of -I/swift/usr/lib/swift/clang/include/ when using lldb, instead of the Swift REPL? (Same question was asked here for related issue SR-3794.)

Example:

ubuntu@mason-linux-2017:~/Code/SORACOM/soracom-sdk-swift$ lldb .build/debug/LinuxDemoAppForSoracomSDK
(lldb) target create ".build/debug/LinuxDemoAppForSoracomSDK"
Current executable set to '.build/debug/LinuxDemoAppForSoracomSDK' (x86_64).
(lldb) b main.swift:7
Breakpoint 1: where = LinuxDemoAppForSoracomSDK`main + 987 at main.swift:7, address = 0x00000000004092eb
(lldb) run
Process 84968 launched: '/mnt/hgfs/Code/SORACOM/soracom-sdk-swift/.build/debug/LinuxDemoAppForSoracomSDK' (x86_64)
Hello, world!
Process 84968 stopped
* thread #&#8203;1, name = 'LinuxDemoAppFor', stop reason = breakpoint 1.1
    frame #&#8203;0: 0x00000000004092eb LinuxDemoAppForSoracomSDK`main at main.swift:7
   4    import SoracomSDKSwift
   5   
   6    let req = SoracomSDKSwift.Request.auth()
-> 7    let res = req.wait()
   8    print(res)
   9   
   10   print("Goodbye, world!")
Target 0: (LinuxDemoAppForSoracomSDK) stopped.
(lldb) po req
error: in auto-import:
failed to get module 'LinuxDemoAppForSoracomSDK' from AST context:
<module-includes>:1:10: note: in file included from <module-includes>:1:
#include "dispatch.h"
         ^

/swift-4.0-DEVELOPMENT-SNAPSHOT-2017-07-06-a-ubuntu16.04/usr/lib/swift/dispatch/dispatch.h:30:10: note: in file included from /swift-4.0-DEVELOPMENT-SNAPSHOT-2017-07-06-a-ubuntu16.04/usr/lib/swift/dispatch/dispatch.h:30:
#include <os/linux_base.h>
         ^

/swift-4.0-DEVELOPMENT-SNAPSHOT-2017-07-06-a-ubuntu16.04/usr/lib/swift/os/linux_base.h:16:10: note: in file included from /swift-4.0-DEVELOPMENT-SNAPSHOT-2017-07-06-a-ubuntu16.04/usr/lib/swift/os/linux_base.h:16:
#include <sys/param.h>
         ^

error: /usr/include/x86_64-linux-gnu/sys/param.h:23:10: error: 'stddef.h' file not found
#include <stddef.h>
         ^

error: could not build C module 'CDispatch'

(lldb) 

NOTE: Original bug was from Swift 3 time frame. I am still seeing it with Swift version 4.0-dev (LLVM a15decabe3, Clang 14ff3d9712, Swift d574ed67d6). The include chain is a bit different than the original example, but it's still choking on stddef.h and I am assuming this is still the same underlying issue.

@swift-ci
Copy link
Collaborator Author

Comment by Matthias M. Schneider (JIRA)

Please see the comment on issue SR-5524 for a possible temporary fix.

@swift-ci
Copy link
Collaborator Author

Comment by Mason Mark (JIRA)

MatiMax (JIRA User) Awesome, thank you! That workaround indeed gets lldb working as well.

To recap: setting the C_INCLUDE_PATH and CPLUS_INCLUDE_PATH environment variables to the Clang header include path did indeed work, not only for getting import Foundation to work in the REPL (without having to use swift -I /my/headers/path), but also for the case of debugging a built executable with lldb (for which I had no workaround).

Example:
(A dev snapshot of Swift 4 is installed at /swift in this example.)

$ 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"
  3> ^C
  3> ^D
$ 
$
$ 
$ lldb ./.build/debug/LinuxDemoAppForSoracomSDK
(lldb) target create "./.build/debug/LinuxDemoAppForSoracomSDK"
Current executable set to './.build/debug/LinuxDemoAppForSoracomSDK' (x86_64).
(lldb) b main.swift:54
Breakpoint 1: where = LinuxDemoAppForSoracomSDK`main + 886 at main.swift:54, address = 0x0000000000409ed6
(lldb) run
Process 2405 launched: './.build/debug/LinuxDemoAppForSoracomSDK' (x86_64)
Hello, world!
Process 2405 stopped
* thread #&#8203;1, name = 'LinuxDemoAppFor', stop reason = breakpoint 1.1
    frame #&#8203;0: 0x0000000000409ed6 LinuxDemoAppForSoracomSDK`main at main.swift:54
   51   
   52   var creds = SoracomSDKSwift.SoracomCredentials.defaultSavedCredentials()
   53   
-> 54   if creds.blank {
   55   
   56       print("No stored credentials found.")
   57       print("Creating initial credentials...")
Target 1: (LinuxDemoAppForSoracomSDK) stopped.
(lldb) po credsSoracomCredentials
  - type : SoracomSDKSwift.SoracomCredentialType.RootAccount
  - emailAddress : "ubuttnu@example.com"
  - operatorID : ""
  - username : ""
  - password : "Ubuttnu123$!"
  - authKeyID : ""
  - authKeySecret : "secret-BeMoTtlusnInAsIsdriBfOmodeerFehTtSFhJJ"
  - apiKey : ""
  - token : ""

(lldb) ^C
(lldb) ^D
$ 

@swift-ci
Copy link
Collaborator Author

Comment by Dave Carlton (JIRA)

Just encountered this on Debian 9.0.

The workaround was swift -I/usr/lib/swift/clang/include/

@swift-ci
Copy link
Collaborator Author

Comment by Christos Vontas (JIRA)

Encountered this on Ubuntu16.10 in a Docker container running as a different than root user.

`chmod o+rw -R /usr/lib/swift/CoreFoundation/` did the trick for me.

@swift-ci
Copy link
Collaborator Author

Comment by Ron Olson (JIRA)

This happens with Swift 4.0.2 on Linux running natively (i.e. not in a container), (Ubuntu as well as compiled from source with Fedora) as well; the workaround to pass the clang headers from the swift installation does work.

@pvieito
Copy link

pvieito commented Mar 7, 2018

Any update on this?

@swift-ci swift-ci transferred this issue from apple/swift-issues Apr 25, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. compiler The Swift compiler in itself
Projects
None yet
Development

No branches or pull requests

3 participants