Remove inlinable from init() to support library evolution on linux#294
Remove inlinable from init() to support library evolution on linux#2942horse9sun wants to merge 1 commit intoapple:mainfrom
Conversation
|
Thanks for this ticket! I'm a little bit surprised to hear you're compiling with library evolution mode on Linux. Swift's ABI is not stable on Linux, and so there is no promise that library evolution mode does anything at all. Can you elaborate a bit on what you're trying to achieve? |
Sorry for the delay :) Here's the brief description of what we're trying to achieve. Out team is responsible for building the infrastructure and platform for company internal use. We're distributing Swift SDKs for plugin development to different teams across the company. Later, we load those plugins (dylibs) to integrate with our platform. One basic requirement is to enable library evolution to ensure backward compatibility and avoid breaking all plugins. It all works fine under macOS environment. However, we have to also make it work under Linux environment for the following reasons:
As you said, "Swift's ABI is not stable on Linux, and so there is no promise that library evolution mode does anything at all". It is true and we have already noticed that every time a new version of our SDK is released, it might break some plugins under Linux environment but not under macOS environment. Currently, our team is also trying to figure out other solutions including disabling library evolution under Linux environment. Anyway, our current workaround to use swift-crypto under Linux environment with library evolution enabled is to take advantage of dependency injection to set the crypto instance at the application level and provide only the protocol in the SDK. It works fine at least for now. Feel free to give any more suggestions :) |
|
Thanks for explaining your use-case, it helps with my understanding. Within a single compiler version, you should be able to do what you want without library evolution mode at all. Given that library evolution mode is not typically supported across the wider Package ecosystem, you may find that the best strategy available to you is to disregard library evolution mode entirely. You can still use dynamic linking, you just have to make sure the compiler and runtime versions all line up. |
Motivation:
I'm currently working on a swift package project which depends on the swift-crypto library. The package is distributed to other teams and built on multiple platforms (macos + linux). Most importantly, the package is required to enable swift library evolution.
However, after the library evolution is enabled, the linux build failed with following error:
The above error can be easily reproduced by:
swift build -c release -Xswiftc -emit-module-interface -Xswiftc -enable-library-evolutionModifications:
After some investigation on this error, I found a useful github issue that may be relevant: swiftlang/swift#62507
As shown in the issue discussion:
Therefore, I just remove "inlinable" from init() of three structs.
Result:
After the modification, it successfully builds on Linux. (At least fix my problem :)
But feel free to give more suggestions on how to support library evolution in the long term instead of just removing these 'inlinable'. Somehow I feel like it's not elegant enough.