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 路径自定义

[gaoguobin]

感谢建议，我这边按照 lib 生成器 的方式测试了一下。

这个方案确实可以传自定义 ar 参数，比如 -rcvD，也能生成 deterministic archive。对需要在生成 ELF 后额外打包一个或多个 lib 的场景来说，这个功能很有用。

不过在纯 output-format: lib 工程里，用起来会有一点不太顺手。因为这类工程本身已经会在正常构建流程里生成主 .a 产物；启用 lib 生成器 后，post-build 又会在 .lib/ 目录下再生成一个 .a。这样最终会有两份库文件：

• 正常 output-format: lib 生成的主 .a；
• post-build lib 生成器 生成的 .lib/*.a。

我也简单对比了一下这两份 .a。解包后的 .o 成员内容是一致的，但 archive 文件本身不只是 timestamp 不同；成员顺序和 archive metadata 也可能不同。因此 .lib/*.a 不太适合作为主输出 .a 的 SHA 等价替代品。

所以对纯 lib 工程来说，如果后续方便的话，还是希望能在正常 output-format: lib 路径上支持可配置 archive flags。这样可以保持原来的输出路径、文件名和构建流程，只把 linker-lib 使用的 ar 参数从：

-rcv ${out} ${in}

配置为类似：

-rcvD ${out} ${in}

这样就不需要额外生成第二份 .a，也能保持现有 EIDE lib 输出流程不变。