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-1192] LLDB swig static binding failure on non-Apple builds #4414
Comments
I have temporarily made a manual edit to the static swig bindings until I can adjust the swig step to make sure the #ifdef in the typemap passes through to the generated file. That temporary change is here: |
It looks like I can use the following swig syntax to support ensuring the #ifdef carries through to the baked file: From the Swig manual: |
Testing a change for this locally. I'll send up in a PR if this generates the code I expect. |
Oops no that's not the right syntax. It looks like I really want: |
I've got the fix in upstream llvm.org svn trunk. I'm waiting on testing of SR-1193 to complete before I submit a PR for this in GitHub. |
Testing the PR for this now: |
Merged in here: |
Additional Detail from JIRA
md5: 46319a25069a6c9cf97f07dc18885c9b
Issue Description:
See build breakage here:
https://ci.swift.org/view/Packages/job/oss-swift-package-linux-ubuntu-14_04/945/console
Swift LLDB builds using builders that do not have swig, and thus use the static swig bindings baked into the build, will fail on non-Apple OSes.
This is due to early evaluation of some new Apple-specific #ifdef code that is happening at swig file generation time instead of at the "compile in the generated binding" code. The net effect is that all systems using the static swig bindings are getting the #ifdef APPLE code erroneously.
In the case of Ubuntu, this is causing the swig binding code to be using some Apple-specific constants and file handling.
This showed up now because this is the first time we've added #ifdef code to the swig Python type maps file.
The text was updated successfully, but these errors were encountered: