lut3d - fix for 4 digits gmic version

[phweyland]

Sorry, you have not seen my message asking for waiting a bit ...
I had forgotten the 4 digits version issue

[TurboGit]

I did not see the message indeed, let's merge this now. Thanks.

[parafin]

What is the point of lut3d_gmic_version function now? It won't return runtime version of the gmic library, but the version dt was compiled with, since gmic_version is a macros, not a variable.

[phweyland]

What is the point of lut3d_gmic_version function now? It won't return runtime version of the gmic library, but the version dt was compiled with, since gmic_version is a macros, not a variable.

I wanted to keep the gmic version along with the compressed clut.
But you are right, if the run time gmic version is different this may be useless.

For windows, the libgmic library is added to dt binaries distribution. So no issue here.
For linux, I've seen dt uses the installed one ... Here we have a strongest issue. dt can crash if the run time version is not the same as the build time one. Is that correct ?
But that is general problem. How the coherence between build time and run time libraries is controlled on linux ?

[phweyland]

I find that to keep gmic version can be interesting if at some point gmic changes some part of compression algorithm. That's a provision. No role today, just trying to keep coherence. Nothing critical.

I can add back the run time version.

I can also remove the version. In that case there are 3 possibilities:

• remove the parameter and the revert back to version 1 (some current edits can fail)
• transform the parameter to a spare one and let the version 2
• remove the parameter and increment again the version.

What do you think ?

[parafin]

So, about library versions, usually backwards compatibility is assumed unless ABI is changed. It means that it's OK to build with older library version and then upgrade a library without recompiling the program. ABI compatibility breakage is handled by changing an ABI version (suffix after .so extension in the filename), so re-linking (and re-compilation) of the program is required. ABI is considered to be changed if some function changed its signature or if some symbol (e.g. function) is removed. Library can add a new function in newer version without breaking ABI, but if user downgrades it to the version below required for the program, the program won't start (or will segfault later) because of unresolved symbols. It's user's/distribution's responsibility not to allow it. There's also symbol versions, but it's more advanced topic.

About saving the version in case behaviour of the library changes - usually it's assumed that any change in behaviour shouldn't break the programs using the library. Otherwise library should provide API to detect such situations, which it seems gmic doesn't do. So it's a question for gmic developers, not us, what do they think of the scenario you described. Also, what do you want to do if you detect version change? Display a message and refuse to work?

I would suggest to remove gmic version from iop params by adding version 3.

[phweyland]

Thanks for the explanation @parafin
I'll remove the version then.