fix(pack): whether stripping applies is a property of the TARGET, not the compiler

Keying `inBandDebugInfo` on `tc.compiler != MSVC` is wrong in both
directions, and each direction is a configuration mcpp ships:

  clang -> x86_64-windows-msvc  produces .pdb debug info, and would have been
                                asked to strip in-band DWARF that is not there.
  Apple clang on macOS          ships no llvm-strip, so the rule would REFUSE
                                every `mcpp pack` on a Mac — for a format whose
                                linked image carries a debug MAP (N_OSO stanzas
                                naming the .o files) and leaves the DWARF
                                outside it. `objcopy --only-keep-debug` there
                                has nothing to copy, and .dSYM is dsymutil's job.

`debug_info_is_in_band(canonicalTriple)` answers it segment-wise from the
canonical triple, which both packers have already resolved. ELF and PE/MinGW
are in-band; Mach-O and the MSVC ABI are not.

Author: speak-agent

src/pack/library_pipeline.cppm

@@ -354,13 +354,12 @@ export int build_and_pack_library(const std::string& targetName,
             .importLibrary = importLib,
             // From THIS leg's toolchain, for the same reason `archiveTool` is:
             // a fat package's foreign leg must not be stripped by the host's
-            // tool. `inBandDebugInfo` is the one bit of "does this even apply"
-            // — PE/MSVC keeps debug information in a separate `.pdb`.
+            // tool. Whether stripping APPLIES is a question about the leg's
+            // TARGET, not about its compiler — see mcpp.pack.strip.
             .stripTools  = mcpp::pack::StripTools{
                 .strip   = mcpp::toolchain::binutils_tool(ctx->tc, "strip"),
                 .objcopy = mcpp::toolchain::binutils_tool(ctx->tc, "objcopy"),
-                .inBandDebugInfo =
-                    ctx->tc.compiler != mcpp::toolchain::CompilerId::MSVC,
+                .inBandDebugInfo = mcpp::pack::debug_info_is_in_band(triple),
             },
         });
         mcpp::ui::status("Packed leg", std::format("{}  [{}]", triple, tag.str()));

src/pack/pipeline.cppm

@@ -21,6 +21,7 @@ import mcpp.pack;
 import mcpp.pack.strip;
 import mcpp.toolchain.model;
 import mcpp.toolchain.registry;
+import mcpp.toolchain.triple;
 import mcpp.ui;
 
 namespace mcpp::pack {
@@ -195,7 +196,16 @@ export int build_and_pack(Options opts, bool modeFromUser,
     plan->stripTools = mcpp::pack::StripTools{
         .strip   = mcpp::toolchain::binutils_tool(ctx->tc, "strip"),
         .objcopy = mcpp::toolchain::binutils_tool(ctx->tc, "objcopy"),
-        .inBandDebugInfo = ctx->tc.compiler != mcpp::toolchain::CompilerId::MSVC,
+        // The CANONICAL triple, resolved the same way the library packer
+        // resolves it: an empty `targetTriple` means "this host", and asking
+        // the empty string would answer "in-band" for macOS and MSVC alike.
+        .inBandDebugInfo = mcpp::pack::debug_info_is_in_band(
+            ctx->tc.targetTriple.empty()
+                ? mcpp::toolchain::triple::host_triple().str()
+                : [&] {
+                      auto t = mcpp::toolchain::triple::parse(ctx->tc.targetTriple);
+                      return t ? t->str() : ctx->tc.targetTriple;
+                  }()),
     };
 
     mcpp::ui::info("Packing", std::format("{} v{} ({}{})",

src/pack/strip.cppm

@@ -39,14 +39,30 @@
 // exact name, so the build-id survives and `--add-gnu-debuglink` still has
 // something to pair with.
 //
-// EMPTY TOOL IS NOT ALWAYS AN ERROR
+// EMPTY TOOL IS NOT ALWAYS AN ERROR, AND WHICH CASE IT IS BELONGS TO THE
+// TARGET FORMAT — NOT TO THE COMPILER
 //
-// PE/MSVC keeps debug information in a separate `.pdb` by design, so there is
-// nothing in-band to remove and no binutils to remove it with. That is
-// `NotApplicable`. Every other format carries DWARF inside the image, so a
-// missing `strip` there is a REFUSAL — the same stance `run_library_pack`
-// already takes for a missing archiver, and for the same reason: shipping the
-// artifact anyway is the silent-wrong-answer this feature exists to remove.
+// Two of the three formats keep debug information OUTSIDE the image, and for
+// them an absent `strip` is the right answer rather than a missing dependency:
+//
+//   PE/MSVC    a separate `.pdb`, by design.
+//   Mach-O     the linked image carries a DEBUG MAP (N_OSO stanzas naming the
+//              `.o` files); the DWARF itself never enters the `.dylib` unless
+//              `dsymutil` is run, and what it then produces is a `.dSYM`
+//              bundle beside the image. `strip` there would remove the symbol
+//              table — a different thing — and `objcopy --only-keep-debug` has
+//              nothing to copy.
+//
+// ELF and PE/MinGW carry DWARF inside the image, so a missing `strip` there is
+// a REFUSAL — the same stance `run_library_pack` already takes for a missing
+// archiver, and for the same reason: shipping the artifact anyway is the
+// silent-wrong-answer this feature exists to remove.
+//
+// ⚠️ KEYING THIS ON THE COMPILER WOULD BE WRONG IN BOTH DIRECTIONS. clang
+// targeting `x86_64-windows-msvc` produces `.pdb` debug info and would be
+// asked to strip in-band; Apple's clang ships no `llvm-strip`, so a
+// compiler-keyed rule would REFUSE every `mcpp pack` on macOS for a format that
+// has nothing to strip in the first place.
 
 export module mcpp.pack.strip;
 
@@ -68,11 +84,19 @@ struct StripTools {
     std::filesystem::path strip;
     std::filesystem::path objcopy;
     // Does this leg's format carry debug information inside the image?
-    // False only for PE/MSVC (`.pdb`). Resolved once by the caller so this
-    // module never has to know what a toolchain is.
+    // Ask `debug_info_is_in_band` rather than filling this by hand — see the
+    // header for the two formats where the answer is no, and for why the
+    // question is about the TARGET and not about the compiler.
     bool                  inBandDebugInfo = true;
 };
 
+// Is debug information carried INSIDE an image built for `canonicalTriple`?
+//
+// A string question about the canonical triple (`arch-os[-env]`), deliberately:
+// this module knows nothing about toolchains, and both packers have already
+// resolved that triple by the time they ask.
+bool debug_info_is_in_band(std::string_view canonicalTriple);
+
 enum class StripOutcome { Stripped, NotApplicable };
 
 struct StripResult {
@@ -131,6 +155,22 @@ std::uintmax_t size_of(const std::filesystem::path& p) {
 
 } // namespace
 
+bool debug_info_is_in_band(std::string_view canonicalTriple) {
+    // `arch-os[-env]`. Splitting rather than substring-matching: an arch or a
+    // vendor segment could contain either of these words, and mcpp has been
+    // bitten before by a triple predicate that answered on a substring.
+    std::vector<std::string_view> seg;
+    for (std::size_t i = 0; i <= canonicalTriple.size(); ) {
+        auto j = canonicalTriple.find('-', i);
+        if (j == std::string_view::npos) { seg.push_back(canonicalTriple.substr(i)); break; }
+        seg.push_back(canonicalTriple.substr(i, j - i));
+        i = j + 1;
+    }
+    if (seg.size() >= 2 && seg[1] == "macos") return false;   // debug map + .dSYM
+    if (seg.size() >= 3 && seg[2] == "msvc")  return false;   // separate .pdb
+    return true;
+}
+
 std::vector<std::string> strip_args(ArtifactShape shape) {
     // dh_strip's own division. See the header for the measurement behind the
     // archive row — it is the one that turns a package into an unlinkable one.

tests/unit/test_pack_relocate.cpp

@@ -307,6 +307,29 @@ TEST(PackStrip, EveryShapeDropsCommentAndNote) {
     }
 }
 
+TEST(PackStrip, WhetherStrippingAppliesIsAskedOfTheTargetNotTheCompiler) {
+    // Keying this on the compiler is wrong in BOTH directions, and each
+    // direction is a real configuration mcpp ships:
+    //
+    //   clang -> x86_64-windows-msvc   produces .pdb debug info; a
+    //                                  compiler-keyed rule would try to strip
+    //                                  in-band DWARF that is not there.
+    //   Apple clang on macOS           ships no `llvm-strip`, so a
+    //                                  compiler-keyed rule would REFUSE every
+    //                                  `mcpp pack` on a Mac — for a format
+    //                                  whose image carries a debug MAP and
+    //                                  leaves the DWARF in the .o files.
+    EXPECT_TRUE (mcpp::pack::debug_info_is_in_band("x86_64-linux-gnu"));
+    EXPECT_TRUE (mcpp::pack::debug_info_is_in_band("aarch64-linux-musl"));
+    EXPECT_TRUE (mcpp::pack::debug_info_is_in_band("x86_64-windows-gnu"));
+    EXPECT_FALSE(mcpp::pack::debug_info_is_in_band("x86_64-windows-msvc"));
+    EXPECT_FALSE(mcpp::pack::debug_info_is_in_band("aarch64-macos"));
+    EXPECT_FALSE(mcpp::pack::debug_info_is_in_band("x86_64-macos"));
+    // Segment-wise, not substring: mcpp has been bitten by a triple predicate
+    // that answered on a substring before.
+    EXPECT_TRUE(mcpp::pack::debug_info_is_in_band("macos64-linux-gnu"));
+}
+
 TEST(PackStrip, MsvcHasNothingInBandToRemove) {
     // PE/MSVC keeps debug information in a separate `.pdb`. An empty `strip`
     // tool there is the right answer, not a missing dependency — and the two