SwiftPM and dynamic linking

[nights99]

Hi,

Probably this is a misunderstanding on my part, but I'd like to convince SPM to do more dynamic library generation/linking, and am finding it hard to do so.

I know I can explicit request a dynamic library in my own Package.swift using "type: .dynamic,", and that works fine and produces the .so as I'd expect (its a .so as I'm on linux for this).

However, if I clone an external package that doesn't specify either static or dynamic, only the static .swiftmodule is generated - is there any way to request a dynamic library without changing the Package.swift?

Similarly though libraries can request dynamic linking, an executable pulling in a package (which again doesn't specify dynamic or static, leaving it to its 'client' AIUI), also gets statically linked, and I can't see an option to request dynamic linking.

Any help much appreciated,
Thanks,
Jon

[nights99]

I started looking into the SPM source, and it turned out to be not too hard to get at least a minimum of what I was looking for working - I have it both producing a dynlib for a external package, and also dynamic linking a sample executable. Is there likely to be any interest in accepting these changes if I looked to tidy them up further?

Thanks,
Jon

[compnerd (Saleem Abdulrasool)]

I'd definitely be interested in seeing that merged - static linking is still not properly available on Windows (mostly from the SPM side). So, getting this support would be great.

[nights99]

I've pushed what I have so far to my fork.

It needs more work - at the least, more comments, documentation and testing.

However if anyone has any comments at this stage, or wants to give it a try, that'd be great. In particular, whether the approach of keeping things as 'automatic' libraries, but modifying the build plan to create products for them, is correct?

Thanks,
Jon

[SDGGiesbrecht (Jeremy David Giesbrecht)]

I definitely would like to take a closer look and possibly help out if it looks promising, but I do not have time at this very moment. I am posting this to let you know so that if I haven’t remembered to get back to you in a week or so, you can ping me with a reminder.

[SDGGiesbrecht (Jeremy David Giesbrecht)]

Okay, so I see you have added --prefer-dynamic, and you have enabled processing of .automatic in several places. (I think it would be better to resolve early whether to divert it into .static or .dynamic mode and then let it simply flow through all the same code branches as the explicit options, but we can get to that later.)

It is not yet clear to me what the precise intended meaning of --prefer-dynamic is. What is supposed to be dynamic?

• Are the toolchain libraries dynamic?
• Are dependency products dynamic? All of them, or just conjunction nodes where it would be useful?
• Should it split .automatic libraries into targets for more fine‐grained heuristics?
• What about libraries in the same package?

Some other important questions:

• Should it (or a companion flag) override explicit .static?
• What happens when an explicit .static ends up in two .dynamic libraries linked into the same executable?
• How does this interplay with inter‐module optimization?
• How much of this would be better as heuristics improvements for the default instead of an explicit option?
• Are we in over our heads and all we really wanted is to produce a .so or .a for a top‐level .automatic library that we then expect to use outside of SwiftPM?

The answers to these questions affect whether it will need to go through the full evolution process and in turn, how much work would be ahead of you.

[nights99]

Thanks for taking the time to look at this, these are all great questions. Let me have a first swing at answering them:

(Apologies if answering inline ends up confusing, but it seemed the easiest way to try and make sure I'd looked at all the questions.)

@SDGGiesbrecht

Okay, so I see you have added --prefer-dynamic, and you have enabled processing of .automatic in several places. (I think it would be better to resolve early whether to divert it into .static or .dynamic mode and then let it simply flow through all the same code branches as the explicit options, but we can get to that later.)

It is not yet clear to me what the precise intended meaning of --prefer-dynamic is. What is supposed to be dynamic?

• Are the toolchain libraries dynamic?

[Jon] By toolchain libraries, do you mean the core libraries like "libswiftCore.so"? Or something else?

• Are dependency products dynamic? All of them, or just conjunction nodes where it would be useful?

[Jon] I think I've made all the dependencies dynamic (I'll check this). This was my intention at least - for my use case, I want most things to be dynamic libraries. e.g. if:

• processA uses modA which uses modC
• processB uses modB which uses modC

then I do want all of modA, modB and modC to be compiled as dynamic libraries.

• Should it split .automatic libraries into targets for more fine‐grained heuristics?

[Jon] Think I need to think about this further. I confess that certainly when I started on the changes, I found the distinction between products and targets unclear; I think I understand it a little better now.

• What about libraries in the same package?

[Jon] Generally I think they should result in a separate .so for each library listed in the products; the question below on "inter‐module optimization" might affect this I guess.

Some other important questions:

• Should it (or a companion flag) override explicit .static?

[Jon] Not something I'd considered, but certainly a possibility. Do you have any feel for how often you've seen ".static" used, rather than leaving it unspecified?

• What happens when an explicit .static ends up in two .dynamic libraries linked into the same executable?

[Jon] I think this should be OK - but I think its definitely worth explicitly trying this to find out - I will do so and report back.

• How does this interplay with inter‐module optimization?

[Jon] I'm relatively new to Swift, so may not be best placed to answer this But yes, I think it will have an effect on e.g. "@inlineable"

Speaking personally, I'd accept that there would be tradeoffs like this for dynamic linking, but:

1. It should definitely be documented
2. It might point towards having different 'modes' for e.g. one .so per package, vs multiple .so's per package - though this might end up being more pain to support

• How much of this would be better as heuristics improvements for the default instead of an explicit option?

[Jon] I did consider this - particularly as it looks like you always get the static library made available as well as the dynamic library artefact. I'd be nervous of changing the default behaviour myself due to a lack of Swift experience.

• Are we in over our heads and all we really wanted is to produce a .so or .a for a top‐level .automatic library that we then expect to use outside of SwiftPM?

[Jon] For my use case I did definitely want more than just a top-level .so, due to the wider system I'm looking to integrate with - but I'm certainly open to input from others here.

The answers to these questions affect whether it will need to go through the full evolution process and in turn, how much work would be ahead of you.

[SDGGiesbrecht (Jeremy David Giesbrecht)]

@SDGGiesbrecht

By toolchain libraries, do you mean the core libraries like "libswiftCore.so"? Or something else?

Yes, that is what I meant. They originate from the Swift toolchain and not from the dependency graph. I ask because there has been recent discussion about changing the defaults for these, which might have some overlap with what we are doing here.

[Pitch] Package Manager: Statically link Swift runtime libraries by default on supported platforms

I do not know why such was not added originally. cc @ddunbar This focus of the proposal is about what would be considered a sensible default. Even if we decide to add some sort of build settings section to the manifest to capture the user's preference (which seems like a good but additive suggestion), SwiftPM would still need to have a default behavior when such are not specified. Right now, that default behavior across all platforms is dynamic linking [of the runtime libraries], but one cou…

@SDGGiesbrecht

• What about libraries in the same package?

[Jon] Generally I think they should result in a separate .so for each library listed in the products; the question below on "inter‐module optimization" might affect this I guess.

Right now a manifest cannot declare a dependency from a target on a product in the same package. It is already confusing to some that a .dynamic product creates a .so, but a neighbouring executable statically links the targets instead. (It is less confusing when the target and product names don’t match, but in many cases they do.) The flag controls you propose would make this quirk more visible and possibly more painful. It might need to be fixed/rethought first.

@SDGGiesbrecht

• Should it (or a companion flag) override explicit .static ?

[Jon] Not something I'd considered, but certainly a possibility. Do you have any feel for how often you've seen ".static" used, rather than leaving it unspecified?

It appears to happen far more often than necessary. SwiftSyntax itself is an example. I suspect this is due to autocomplete presenting the field for type, and users reaching for .static without knowing about the .automatic enum case. (They are not even the same; .static creates a .a in the products directory, automatic does not.)

@SDGGiesbrecht

• How does this interplay with inter‐module optimization?

[Jon] I'm relatively new to Swift, so may not be best placed to answer this But yes, I think it will have an effect on e.g. "@inlineable"

That is only part of what I mean. Already static linking can do some dead stripping, specialization, etc. and it is getting better with time. Theoretically the same optimizations ought to be possible for dynamic‐linked libraries built together in the dependency graph, but I do not think any of this has been implemented yet. So is the worse size and speed acceptable in the meantime, and does it need to be communicated to users somehow? Also, if a package is an executable‐dynamic library pair, where one uses the other, should the dynamic library be stripped down to only what the executable actually uses or not? Do you know of any other ramifications I have not thought of yet?

[ColemanCDA (Alsey Coleman Miller)]

We use Swift on ARMv7 Linux (Yocto) on a commercial IoT device for a couple years now. For resource constrained devices having the runtime as a dynamic library is optimal, and we even try to build SwiftPM libraries as dynamic when it makes sense. Making the stdlib static by default would increment binary size a lot, and should not be the default given that you do need more resources to run that larger binary. The default setting should always favor minimal resource usage. Also its not only SwiftCore that would be bundled, but Dispatch, Foundation and SwiftConcurrency modules. What's the story for CURL, ICU and LibXML2? I think having every single Swift library statically link all that by default is insane, and just linking the stdlib is inconsistent since a simple Hello world program with DateFormatter requires all of the above.

I have a custom Buildroot fork that runs Swift 5.6 on an Armv5 chip with 64mb of RAM. If this proposal is accepted, I would have to make an extra effort to efficiently run on resource constrained devices that work incredibly well right now.

Furthermore, with the plans for distributing official RPM and DEB packages, this makes absolutely no sense. Not all usage of Swift on Linux is server or Docker containers. Even though the Swift stdlib is not ABI stable on Linux officially, I have been able to run the same binary (dynamically linked) with different compiled std libs (Yocto and Buildroot recipes, Debian as well) without missing symbols, at least for new patch versions (e.g. Swift 5.5 -> 5.5.3, Swift 5.6 -> 5.6.1)