Support configurable archive flags for output-format: lib

[gaoguobin]

Summary

Please consider adding a way to configure archive (ar) flags for projects using output-format: lib.

At the moment, the ARM GCC model appears to route output-format: lib to the linker-lib tool, whose command template is fixed as:

"linker-lib": {
  "$path": "bin/${toolPrefix}ar",
  "$output": "-rcv ${out} ${in}",
  "$outputSuffix": ".a"
}

Because this command is model-defined, the existing Linker UI fields such as "Other Linker Options" / "Lib Flags" do not seem to provide a way to pass archive-specific flags such as GNU ar's D modifier.

Use case: reproducible library builds

For GNU ar, deterministic archives can be produced with D, for example:

arm-none-eabi-ar rcvD libfoo.a foo.o bar.o
# or rcsD if the symbol index should be created in the same step

Without D, repeated clean rebuilds of the same library project can produce .a files with different SHA-256 values, even when the object files themselves are unchanged. arm-none-eabi-ar tv shows archive member timestamps being set to the current build time.

This makes it difficult to use artifact SHA-256 values as provenance/reproducibility checks in CI.

Reproduction outline

1. Create or open an ARM GCC project.
2. Set Linker -> Output Format to LIB.
3. Rebuild the project twice from unchanged source.
4. Compare the SHA-256 of the generated .a file.
5. Inspect the archive metadata:

arm-none-eabi-ar tv build/<target>/*.a

Observed behavior: archive member timestamps change between rebuilds, so the .a SHA changes. Individual .o files remain stable.

Suggested behavior

A project-level option for archive flags would make this configurable without changing behavior for existing users. For example:

• Add an "Archive Flags" / "AR Flags" option for output-format: lib.
• Keep the current default compatible with existing behavior, e.g. -rcv.
• Allow users to set -rcvD or -rcsD for deterministic archives.

Another possible approach is to make the linker-lib.$output template overridable per project/toolchain configuration.

Environment where this was observed

• EIDE: 3.27.0
• Toolchain: xPack GNU Arm Embedded GCC 15.2.1
• GNU ar / binutils: 2.45.1
• Platform: Windows

Thanks.

[gaoguobin]

Additional local evidence and a broader configuration request:

I checked the generated builder.params from a real ARM GCC library project. Sanitized paths below:

{
  "toolchain": "GCC",
  "toolchainLocation": "<user-home>/.eide/tools/xpack-arm-none-eabi-gcc-15.2.1-1.1",
  "toolchainCfgFile": "<user-home>/.vscode/extensions/cl.eide-3.27.0/res/data/models/arm.gcc.model.json",
  "options": {
    "global": {
      "toolPrefix": "arm-none-eabi-"
    },
    "linker": {
      "output-format": "lib",
      "$use": "linker-lib"
    }
  }
}

The selected model then resolves linker-lib as:

"linker-lib": {
  "$path": "bin/${toolPrefix}ar",
  "$output": "-rcv ${out} ${in}",
  "$outputSuffix": ".a"
}

So for this project the actual archive tool is:

<user-home>/.eide/tools/xpack-arm-none-eabi-gcc-15.2.1-1.1/bin/arm-none-eabi-ar.exe

with:

GNU ar (xPack GNU Arm Embedded GCC x86_64) 2.45.1.20251203

The deterministic archive flag D is only one concrete use case. Ideally this should not be limited to a dedicated deterministic-only checkbox. A more flexible solution would be to let projects configure the archive tool command/options more generally, for example:

• expose generic AR Flags / Archive Flags for output-format: lib;
• or allow overriding the linker-lib.$output template at project/toolchain level;
• keep the current default -rcv ${out} ${in} for backward compatibility;
• allow users to choose values such as -rcvD ${out} ${in}, -rcsD ${out} ${in}, --thin, --plugin, --target, --record-libdeps, etc. when their toolchain supports them.

That would solve reproducible archive builds without blocking other valid GNU ar options that may be needed later.

[github0null]

后面会进行改进的。

---

就目前而言，更好的替代方法是使用 lib 生成器，它作为 post-build 任务执行，因此可以在生成 elf 的同时也一并生成 lib, 可以一次生成多个 lib, 也支持 ar 参数的自定义 和 ar 路径自定义