[cfe-dev] How to package library TSes

Ted Kremenek kremenek at apple.com
Tue Jul 28 10:06:40 PDT 2015


> On Jul 28, 2015, at 12:39 AM, David Chisnall <David.Chisnall at cl.cam.ac.uk> wrote:
> 
> 
> 
>> On 28 Jul 2015, at 00:51, Ted Kremenek <kremenek at apple.com> wrote:
>> 
>> On OS X, we can do something similar to how we are handling the Swift runtime:
>> 
>> - Build the TSes in a separate dylib, and distribute that dylib (with its headers) with the compiler.
>> 
>> - When building an app that uses a TS, embed the dylib for the TS inside the app bundle itself.
>> 
>> - The embedded dylib would need to be ABI compatible with the core libc++ dylib on the host system, but that’s as far as it would need to go.  As the TSes evolve, the dylib would change and the app would need to get rebuilt anyway when it picks up a new compiler.
> 
> I’m assuming that this means that you don’t support using the TSs inside third party binary-only frameworks? Or does the two-level linking namespace thing manage this for things that don’t expose TS types in headers?

Sorry, let me elaborate.

I think the easiest way to think about this is imagine the TS is packaged in its own 3rd party framework.  That framework could be used by any other framework in a users application, or even other 3rd party frameworks.  On Darwin, that TS framework could be embedded inside the app, and used by both the application and 3rd party framework.

Such a framework would suffer from the same problems as any C++ library.  The ABI/API might not be stable, and thus likely only could support a model where the 3rd party frameworks and application that use the TS framework are all built with the same compiler (assuming the TS library ships with the compiler).

> 
>> The major downside of this approach is that it creates an expectation of backwards deployment to earlier OSes, even if the TS makes it into the core libc++ dylib on the host system at a later stage.
> 
> Wouldn’t weak linking address or filter libraries address this?

I’m not certain what you mean by using weak linking.  Here’s how I see it:

(1) The TS framework ships inside the app, not with the OS.  Let’s say this is OS version 1.

(2) The APIs move to the core libc++ library at a later OS release.  Let’s say this is OS  version 2.

How is the application build if it wants to deploy to running on the earlier OS release (i.e., OS version 1)?  There is no copy of the library on the OS, so all it could do is continue to embed it if it wanted to deploy to the earlier OS release.  On the Mac, many mainstream C++ apps deploy back several OS releases (for many years), and thus bundling the library with the compiler means that library would need to ship with the compiler long after the core functionality of that library migrates to the main libc++ library.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20150728/ae4b20c1/attachment.html>


More information about the cfe-dev mailing list