Explicitly set the type of the SPM library to be dynamic.
Motivation:
When a binary target-type framework consumer specifies swift-log as a transitive dependency, the swift-log symbols that the framework depends on are statically linked in that framework's binary. As a result, consumers of said framework resolve the swift-log transitive dependency which is made available as a dynamic library at runtime - meaning duplicate symbols are present in two (or more) different dynamic libraries causing "Class is implemented in both..." warning logs.
Downstream app warning logs at runtime:
Proof of swift-log symbols being statically linked in my binary framework consumer:
Modifications:
To resolve this, I have explicitly set the SPM library type of swift-log to 'dynamic'. This means binary target-type consumers link swift-log dynamically.
Result:
Binary target-type framework consumers of swift-log will get the same experience as regular source-code consumers of swift-log as swift-log will be linked dynamically rather than statically.
I've tried and tested this fork in an app which resolves my binary target-type framework through SPM and swift-log (as a transitive dependency) and I no longer get those warnings.
Proof of swift-log symbols no longer being statically linked to binary target-type consumers after my change:
Explicitly set the type of the SPM library to be dynamic.
Motivation:
When a binary target-type framework consumer specifies swift-log as a transitive dependency, the swift-log symbols that the framework depends on are statically linked in that framework's binary. As a result, consumers of said framework resolve the swift-log transitive dependency which is made available as a dynamic library at runtime - meaning duplicate symbols are present in two (or more) different dynamic libraries causing "Class is implemented in both..." warning logs.
Downstream app warning logs at runtime:
Proof of swift-log symbols being statically linked in my binary framework consumer:
Modifications:
To resolve this, I have explicitly set the SPM library type of swift-log to 'dynamic'. This means binary target-type consumers link swift-log dynamically.
Result:
Binary target-type framework consumers of swift-log will get the same experience as regular source-code consumers of swift-log as swift-log will be linked dynamically rather than statically.
I've tried and tested this fork in an app which resolves my binary target-type framework through SPM and swift-log (as a transitive dependency) and I no longer get those warnings.
Proof of swift-log symbols no longer being statically linked to binary target-type consumers after my change: