Martin Liška

> It is odd that GCC defined only the enums for the v3 API and didn't implement the feature. Note the header file is shared among binutils and compilers (GCC,...

> Martin, also in addition to skipping resolution file emission, we probably want to take the file away from lto1 command line, so it is not parsed (at least from...

> @marxin I built your gcc branch and try to compile a few programs. mold can be built with your gcc+mold with -flto, which is great. That are great news!...

> The usual way to figure out the linker plugin version is by seeing what get_symbols_v? variant was called. This was OK with V1->V2 update since the API was backward...

About the detection of if `get_symbols_v3` is used. I'm suggesting the following extension to the plug-in API that provides a name and compiler version of a linker. Note it's very...

> I think that the string-based version detection is a bit fragile and can cause chaos just like web browser's User-Agent string. I could imagine that other compiler would have...

> I don't want to identify the whole compiler's version but each feature's version. I want to know whether or not a given linker plugin supports version N of feature...

Looking at both `bfd` and `gold`, they are really responsible for fd closure: bfd: ```c static int try_claim (bfd *abfd) { int claimed = 0; struct ld_plugin_input_file file; file.handle =...

> There is a workaround, but it's pretty ugly. #362 Why is it ugly? Apparently, the GCC LTO plugin implementation (which is older), does not close the descriptors and the...

Well, that brings us back to the suggested `tv_plugin_version` callback. I know the situation is not ideal, but such detection seems to be reasonable. You can detect the GCC plugin...