objcopy isn't sweaty

[andrewrk]

zig/lib/compiler/objcopy.zig

Lines 823 to 829 in e4abdf5

	// note: this is "a minimal effort implementation"
	// It doesn't support all possibile elf files: some sections type may need fixups, the program header may need fix up, ...
	// It was written for a specific use case (strip debug info to a sperate file, for linux 64-bits executables built with `zig` or `zig c++` )
	// It moves and reoders the sections as little as possible to avoid having to do fixups.
	// TODO: support non-native endianess
	fn ElfFile(comptime is_64: bool) type {

This isn't up to zig project standards.

zig/test/standalone/stack_iterator/build.zig

Lines 107 to 108 in e4abdf5

	// zig objcopy doesn't support incremental binaries
	.use_llvm = true,

👎 👎

[xxxbxxx]

In case it is useful to someone other than me:
I've ported the old 0.14.1 code to 0.15.1 in this package:
https://codeberg.org/xbx/cc_helper

(as a side note, it is soo nice to experience the 'reusable' part of the zig tagline: being able to actually just grab the objcopy.zig file from the compiler source tree and run it as-is in an other context, no fiddling with include paths or whatever. lovely!)

[Parzival-3141]

I've started work on this here.

My goal is to support the most common operations on the most common object formats.
In other words: support adding/removing/configuring/compressing sections and symbols for ELF, COFF, and MachO objects.

Conversion between object formats (besides "raw" formats like binary, ihex, etc.) is intentionally unsupported. This feature is rarely used and requires a huge amount of complexity in return. GNU is the only vendor that implements it and built a dedicated library to do it. LLVM drops this feature as well, although it does support converting between ELF types (endianness, architecture, 32/64bit). Zig users should either compile with the desired -ofmt or depend on GNU objcopy.

Hopefully that's sweaty enough.