Merge bitcoin/bitcoin#23617: doc: Fix typos in packages.md

83c08ba0c97798e7da2d4e74722ece534d0f8620 doc: Fix typos in packages.md (Hennadii Stepanov)

Pull request description:

ACKs for top commit:
  theStack:
    ACK 83c08ba0c97798e7da2d4e74722ece534d0f8620
  Zero-1729:
    ACK 83c08ba0c97798e7da2d4e74722ece534d0f8620
  brunoerg:
    ACK 83c08ba0c97798e7da2d4e74722ece534d0f8620

Tree-SHA512: d6b192ecf10254943c6be0762a512258642862992d28834b0429d5b95601192da60058cf1d72fd1a4e5834b56e11776aa8b994b7947d3d29d6592617b9d875ef
This commit is contained in:
fanquake 2021-11-29 09:05:36 +08:00 committed by pasta
parent a1ecac0f61
commit 12b6efe874
No known key found for this signature in database
GPG Key ID: 52527BEDABE87984

View File

@ -178,6 +178,6 @@ not sufficient to just say `libprimary`.
For us, it's much easier to just link a static `libsecondary` into a shared For us, it's much easier to just link a static `libsecondary` into a shared
`libprimary`. Especially because in our case, we are linking against a dummy `libprimary`. Especially because in our case, we are linking against a dummy
`libprimary` anyway that we'll throw away. We don't care if the end-user has a `libprimary` anyway that we'll throw away. We don't care if the end-user has a
static or dynamic `libseconday`, that's not our concern. With a static static or dynamic `libsecondary`, that's not our concern. With a static
`libseconday`, when we need to link `libprimary` into our executable, there's no `libsecondary`, when we need to link `libprimary` into our executable, there's no
dependency chain to worry about as `libprimary` has all the symbols. dependency chain to worry about as `libprimary` has all the symbols.