Implement ahc-ar

[TerrorJack]

Is your feature request related to a problem? Please describe.
When using ahc-cabal to compile library components, it calls ar to make the static library archives from the object files. Later at link time, ahc-ld would decode the objects in the archives before further linking logic.

Relying on system ar introduces a hidden dependency on gnu ar; the default ar on darwin doesn't support the .rsp files passed to it, which results in boot failures, as seen in #345. It's possible to workaround the issue by installing gnu binutils on darwin, but that's a heavyweight change in the user environment we'd like to avoid.

The more ideal solution is implementing a simple ahc-ar program and specify it as the ar program in the ahc-cabal default configuration flags. There are additional benefits besides fixing darwin support, see below.

Describe the solution you'd like

• Implement ahc-ar which recombines multiple object files into a single one, and output the combined object file as the "archive" file. Cabal doesn't care whether .a is a real archive and it's going to be handled by ahc-ld anyway. This will increase some compile time in exchange for shorter link time.
• Simplify ahc-ld and TH loader logic, handle .a files just like regular .o files
• Make ahc-cabal use ahc-ar as the default ar program

[TerrorJack]

Blocked by haskell/cabal#6823. So, for now, we can't name the custom ar executable as ahc-ar and make ahc-cabal recognize it as the ar executable. I'll take a quick look into cabal codebase to see whether we can fix this upstream.

[TerrorJack]

Just figured it out; specifying "-a" "program-locations\n ar-location: /bin/my-custom-ar" would work.

[gkaracha]

The more ideal solution is implementing a simple ahc-ar program and specify it as the ar program in the ahc-cabal default configuration flags.

@TerrorJack Which parts of ar should ahc-ar implement? I mean both in terms of (a) functionality and (b) usage interface. Would be a pity to have to re-implement the whole thing

[TerrorJack]

Only the functionality used by ahc-cabal to create pseudo-archives.

[gkaracha]

Only the functionality used by ahc-cabal to create pseudo-archives.

@TerrorJack Right. Since we are deviating from ar anyway, some of my thoughts:

Shall we deviate from the "original" archiving style w.r.t flags also? We know we always call ahc-ar with -r, -c so I would just hardwire the expected behavior into ahc-ar (that's what I am currently doing, but I still pass the flags, which ahc-ar simply ignores).

I am also thinking: is there any good reason to keep the traditional .a format? I noticed that when we parse archive files, we always ignore the metadata anyway, and my current implementation of ahc-ar generates default metadata and it works just fine. I'd just drop the metadata from the .a files we generate.

Is that what you had in mind?

[TerrorJack]

@gkaracha Nope; what I had in mind is:

• ahc-ar is called, and receives the input object file paths via the .rsp script
• ahc-ar would try to decode each object file as asterius object and combine them; there may be decoding failures since some may be generated by the host gcc, in which case they're silently ignored
• The combined object is then serialized to the .a file
• Later at link time, there's no more logic to handle the .a files as archives; we simply deserialize them just like how we deserialize .o files