On Thu, Jun 30, 2022 at 10:42 AM Martin Liška <mli...@suse.cz> wrote: > > On 6/30/22 08:43, Rui Ueyama wrote: > > Thanks Martin for creating this patch. > > You're welcome. > > > > > Here is a preliminary change for the mold side: > > https://github.com/rui314/mold/commit/9ad49d1c556bc963d06cca8233535183490de605 > > > > <https://github.com/rui314/mold/commit/9ad49d1c556bc963d06cca8233535183490de605> > > > > Overall the API is looking fine, > > Good then! > > > though it is not clear what kind of value is expected as a linker version. > > A linker version is not a single unsigned integer but something like > > "1.3.0". Something like "1.3.0-rc2" can also be a linker version. So I > > don't think we can represent a linker version as a single integer. > > Well, you can use the same what we use GCC_VERSION (plugin_version): > > 1000 * MAJOR + MINOR > > Let me adjust the documentation of the API.
Hmm, but then why not go back to the original suggestion merging linker_identifier and linker_version into a single string. That of course puts the burden of parsing to the consumer - still that's probably better than imposing the constraint of encoding the version in an unsigned integer. Alternatively easing parsing by separating out the version in a string would be possible as well (but then you'd have to care for 1.3.0-rc2+gitab4316174 or so, not sure what the advantage over putting everything in the identifier would be). You usually cannot rely on a version anyway since distributors usually apply patches. > Richi: May I install the patch? Let's sort out the version thing and consider simplifying the API. Richard. > Thanks, > Martin > > > > > On Mon, Jun 20, 2022 at 9:01 PM Martin Liška <mli...@suse.cz > > <mailto:mli...@suse.cz>> wrote: > > > > On 6/20/22 11:35, Richard Biener wrote: > > > I think this is OK. Can we get buy-in from mold people? > > > > Sure, I've just pinged Rui: > > https://github.com/rui314/mold/issues/454#issuecomment-1160419030 > > <https://github.com/rui314/mold/issues/454#issuecomment-1160419030> > > > > Martin > >
