# Swift Packages in multiple targets results in “This will result in duplication of library code.” errors

**URL:** <https://forums.swift.org/t/swift-packages-in-multiple-targets-results-in-this-will-result-in-duplication-of-library-code-errors/34892>\
**Category:** Using Swift\
**Tags:** xcode, packagemanager\
**Created:** [March 28, 2020, 4:35pm UTC](https://forums.swift.org/t/swift-packages-in-multiple-targets-results-in-this-will-result-in-duplication-of-library-code-errors/34892 "2020-03-28T16:35:48Z")\
**Posts on this page:** 1\
**Showing post:** 36

<div class="post-metadata">

**Author:** ![rsebbe](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/rsebbe/32/4600_2.png) [@rsebbe](https://forums.swift.org/u/rsebbe)\
**Post date:** [July 30, 2020, 12:56pm UTC](https://forums.swift.org/t/swift-packages-in-multiple-targets-results-in-this-will-result-in-duplication-of-library-code-errors/34892/36 "2020-07-30T12:56:54Z")

</div>

yes. We use "stub" dynamic libs because we know dynamic libs are never linked into a static lib, yet correctly setup build oder and module generation.

Again, this is a workaround. I'd rather not have such stub libs at all, and just declare **depends\_on** and **link\_against** relationships in Xcode. The former is not possible across targets in distinct projects in an Xcode workspace, only the latter is, which is why we need these stubs in the first place.

Hopefully SPM is smarter here, and we can progressively replace Xcode lib targets with SPM, which will do the right thing.

---

_[View the full topic](https://forums.swift.org/t/swift-packages-in-multiple-targets-results-in-this-will-result-in-duplication-of-library-code-errors/34892)._