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

Closed
ankitspd opened this issue Feb 5, 2017 · 1 comment
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. compiler The Swift compiler in itself legacy driver Area → compiler: the integrated C++ legacy driver. Succeeded by the swift-driver project

Comments

@ankitspd
Copy link
Member

ankitspd 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

duplicates:

  • 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 https://bugs.swift.org/browse/SR-3280 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"
print(str)

$ 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?

@belkadan
Copy link
Contributor

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
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. compiler The Swift compiler in itself legacy driver Area → compiler: the integrated C++ legacy driver. Succeeded by the swift-driver project
Projects
None yet
Development

No branches or pull requests

2 participants