From 116062100aaec4351d4af2789d6fe68d9f8cc747 Mon Sep 17 00:00:00 2001 From: fanquake Date: Mon, 29 Nov 2021 09:05:36 +0800 Subject: [PATCH] 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 --- depends/packages.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/depends/packages.md b/depends/packages.md index 7ed20ea1297dc..4158b46d28d87 100644 --- a/depends/packages.md +++ b/depends/packages.md @@ -178,8 +178,8 @@ not sufficient to just say `libprimary`. 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` 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 -`libseconday`, when we need to link `libprimary` into our executable, there's no +static or dynamic `libsecondary`, that's not our concern. With a static +`libsecondary`, when we need to link `libprimary` into our executable, there's no dependency chain to worry about as `libprimary` has all the symbols. ## Build targets: