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-3863] swift emits a temporary swiftmodule when swiftmodule of main module is passed with -emit-executable #46448

aciidb0mb3r opened this issue Feb 5, 2017 · 1 comment


Copy link

@aciidb0mb3r aciidb0mb3r commented Feb 5, 2017

Previous ID SR-3863
Radar None
Original Reporter @aciidb0mb3r
Type Bug
Status Resolved
Resolution Duplicate
Additional Detail from JIRA
Votes 0
Component/s Compiler
Labels Bug, Driver
Assignee None
Priority Medium

md5: d9ab529c699f3022365b81a2ce367a09


  • SR-2660 Teach the driver to accept multiple swiftmodules as linker inputs, for static linking

relates to:

  • SR-3280 Package manager should link main swiftmodule in executables

Issue Description:

I am not really sure if this a bug or not. Basically I am trying to fix by passing swiftmodule file of main executable along with objects in swiftpm's link command.

It works but swift tries to generate a temporary module which makes it want all the search paths again. For example this is what happens on linux:

$ cat main.swift
let str = "Hello world"

$ swiftc -module-name foo -g -emit-object -c main.swift
$ swiftc -module-name foo -g -emit-module -emit-module-path foo.swiftmodule main.swift

Now, as per SR-3280, this produces executable but is not debuggable.
$ swiftc -module-name foo -g -o foo -emit-executable main.o
$ lldb foo -o "b main.swift:2" -o r -o "po str" -b

(lldb) po str
error: in auto-import:
failed to get module 'foo' from AST context

Passing swiftmodule makes the executable debuggable as expected:
$ swiftc -module-name foo -g -o foo -emit-executable main.o foo.swiftmodule
$ lldb foo -o "b main.swift:2" -o r -o "po str" -b

(lldb) po str
"Hello world"

But it also generates an intermediate swiftmodule:
$ swiftc -module-name foo -g -o foo -emit-executable main.o foo.swiftmodule -###

/usr/bin/swift-autolink-extract main.o -o /tmp/main-d50a74.autolink
/usr/bin/swift -frontend -emit-module foo.swiftmodule -parse-as-library -target x86_64-unknown-linux-gnu -disable-objc-interop -g -emit-module-doc-path /tmp/foo-0b3cfe.swiftdoc -color-diagnostics -module-name foo -o /tmp/foo-0b3cfe.swiftmodule
/usr/bin/swift -modulewrap /tmp/foo-0b3cfe.swiftmodule -target x86_64-unknown-linux-gnu -o /tmp/foo-429e33.o
/usr/bin/clang++ -fuse-ld=gold -target x86_64-unknown-linux-gnu -Xlinker -rpath -Xlinker /usr/lib/swift/linux /usr/lib/swift/linux/x86_64/swift_begin.o /tmp/foo-429e33.o main.o -L /usr/lib/swift/linux -lswiftCore --target=x86_64-unknown-linux-gnu @/tmp/main-d50a74.autolink /usr/lib/swift/linux/x86_64/swift_end.o -o foo

Shouldn't swift not do that because it already has foo.swiftmodule and run the modulewrap command directly?

Copy link

@belkadan belkadan commented Feb 7, 2017

I think I'm going to consolidate this with SR-2660. We need to distinguish the goal of emitting modules from including modules for linking purposes.

@swift-ci swift-ci transferred this issue from apple/swift-issues Apr 25, 2022
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet

No branches or pull requests

2 participants