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-7388] lldb on Linux broken further with Swift 4.1 (error: could not build C module 'SwiftGlibc') #4374
Comments
@swift-ci create |
please also note that this is a really bad bug and I don't currently have a workaround: This stops you from working with LLDB for any module that (transitively) depends on |
@adrian-prantl, @compnerd, I thought we backed out the change that caused this? |
Yeah I thought that this would be fixed by shipping the correct clang headers with LLDB, but we don't have a testcase that imports glibc in the Swift LLDB Linux testsuite at the moment. I'll add one and see if I can reproduce this. |
@swift-ci create |
Does this also reproduce for with a recent trunk development snapshot (https://swift.org/download/#snapshots),) and without setting any additional environment variables the alter the Clang include path? If it doesn't reproduce, then this bug is a duplicate of https://bugs.swift.org/browse/SR-6954. The workaround then is to move the clang headers inside of lldb into a subdirectory with the lldb version number: |
@adrian-prantl, sorry for the late response. This is the state with the the latest snapshot (
so for my example it seems to work. However, using a slightly more complicated project:
so it still doesn't work 🙁. Note we're on Linux here so the "OS X 10.10 / iOS 8 SDKs or later" message doesn't really make sense. I used swift-nio at hash nio repro:
and then to trigger the break point, use a different terminal and run
then you should have hit the breakpoint, and then you can run:
to repro |
@adrian-prantl and just to prove that with 4.0.3 and the same code it works just fine
|
@adrian-prantl sorry for the spam, I couldn't do the
|
This should be fixed in swift-4.2-branch f7c80dd or later. Please let me know if you run into further problems! |
thanks very much @adrian-prantl, now fixed with
|
Awesome. Please do let me know if you find any other issues! |
@weissi is it possible to add this as an integration test to the integration test repo? Seems like something small we could put there. I am surprised that it was not caught earlier. |
Just for completeness: I did add a end-to-end test to LLDB that imports libdispatch, when I fixed this. |
thanks @adrian-prantl, that's great to hear! |
Comment by Tabor Kelly (JIRA) I would appear that this is still broken in the Ubuntu 16.04 Swift 4.1.1 release. Would it be possible to get this into a stable release? |
Yes, the fix is only on the swift-4.2 branch. I'll investigate whether it can be backported to 4.1. |
I created a pull request here: apple/swift-lldb#614 |
The pull request has been merged onto swift-4.1-branch. |
Attachment: Download
Additional Detail from JIRA
md5: 48024bbb57e421386b584d49266538c4
Issue Description:
Up to Swift 4.0 to get lldb to work on anything that uses the
Glibc
orFoundation
module, you just do thisbefore starting
lldb
and it'll work. That is filed as SR-5524 . In Swift 4.1 though even that fails 🙁expected
demo in the working state (4.0.3):
actual (Swift 4.1)
which as shown above throws this error
oddly enough, in the REPL, exporting
C_INCLUDE_PATH
still seems to work:which shows that the import works fine. For the record, not having
C_INCLUDE_PATH
exported makes the REPL fail with the same error:please note: This is best tested in a Docker container as LLDB seems to heavily cache both positive and negative results. So sometimes reproductions are hard because LLDB cached something that previously worked (or the other way around).
The text was updated successfully, but these errors were encountered: