[PATCH] D116913: [lld-macho] Add --start-lib --end-lib

Wed Jan 19 11:59:50 PST 2022

MaskRay added a comment.

In D116913#3255820 <https://reviews.llvm.org/D116913#3255820>, @jyknight wrote:

> Sorry I didn't see to comment on this before, but I'm also skeptical about introducing a new concept of stateful options to this command-line syntax.
>
>> (b) --start-lib a.o b.o --end-lib conveys more
>> information than an alternative design: -objlib a.o -objlib b.o because
>> --start-lib makes it clear which objects are in the same conceptual archive.
>
> I don't think this is relevant to this linker -- what flexibility are you imagining it provides? "Conceptual archive" doesn't mean anything to a Mach-O linker, since we don't have the legacy ELF symbol lookup behavior where you need to loop around and search an archive repeatedly to find the proper files to pull into the link.

If we later discover that linking `x.a(a.o b.o) y.a(c.o)` has different behavior than `x.a(a.o) y.a(b.o c.o)`, with --start-lib, since we have the library boundary information, we can fix it.
With `-objlib`, we can't.
I wouldn't put my bet on that Mach-O archives will never introduce such a rule (or has already such a rule but we just don't know yet), given weird options like `-ObjC`.

If an archive is augmented with special `__.*` members doing weird stuff, with --start-lib we can port it.
With `-objlib`, we can't.

>> (c) -objlib/-filelist interaction may be weird.
>
> Filelist can _only_ contain files, no options, so I don't see how this is an advantage of --start-lib? Also, the use of -filelist should be considered deprecated -- passing the args directly to Clang, via a clang @ response-file if needed, is preferable in every way.

I used this as a very weak argument. I think it is fine to argue this in both ways. `--start-lib` makes it easy to use `--start-lib @response.rsp --end-lib`.

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D116913/new/

https://reviews.llvm.org/D116913