calc

calc copied to clipboard

Hi @lcn2 .

$ ldd calc 
        ...
        libcalc.so.2.14.1.0 => ~/git/calc/libcalc.so.2.14.1.0 (0x00007fafa43dd000)
        libcustcalc.so.2.14.1.0 => ~/git/calc/libcustcalc.so.2.14.1.0 (0x00007fafa43d4000)
        ...

Shouldn't it link to the SO (MAJOR) version?:

        libcalc.so.2 => ...
        libcustcalc.so.2 => ...

And name libcustcalc. Maybe libcalccust?

To be sure of what you are suggesting, you request that we should form links such as:

libcalc.so => libcalc.so.2
libcustcalc.so => libcustcalc.so.2
libcalc.so.2 => libcalc.so.2.14
libcustcalc.so.2 => libcustcalc.so.2.14
libcalc.so.2.14 => libcalc.so.2.14.1
libcustcalc.so.2.14 => libcustcalc.so.2.14.1
libcalc.so.2.14.1 => libcalc.so.2.14.1.0
libcustcalc.so.2.14.1 => libcustcalc.so.2.14.1.0

.. or something else?

And do this during install only or ..?

Please elaborate @zvezdochiot, thanks 🙏

Hi @lcn2 .

Yes. And so that calc refers to the MAJOR version, and is not rigidly tied to a specific release of the library.

Hi @lcn2 .

Yes. And so that calc refers to the MAJOR version, and is not rigidly tied to a specific release of the library.

A bit of background on calc versions as a FYI:

While incompatible changes to the calc library (such as new builtin functions, enhancements to existing builtin functions, etc.) when the MINOR_VER (currently 2.14) level changes, significant impact to the calculation engine can occur at the MAJOR_PATCH (currently 2.14.1) level that could impact the relationship between calc and the library.

To complicate things even more, when we are releasing non-production version so calc (in order to receive wider feedback from the community who is willing to test new version of calc), important bug fixes can occur at even the MINOR_PATCH level (currently 2.14.1.0). An experimental non-production release might go thru several MINOR_PATCH versions before a stable production version is declared. For example we might start with a non-production version 2.14.2.0 and go thru a few iterations (2.14.2.1 .. 2.14.2.2 .. 2.14.2.3 ) before a stable production version 2.14.2.4 were declared.

=-=

In addition to this linking scheme:

libcalc.so => libcalc.so.2
libcustcalc.so => libcustcalc.so.2
libcalc.so.2 => libcalc.so.2.14
libcustcalc.so.2 => libcustcalc.so.2.14
libcalc.so.2.14 => libcalc.so.2.14.1
libcustcalc.so.2.14 => libcustcalc.so.2.14.1
libcalc.so.2.14.1 => libcalc.so.2.14.1.0
libcustcalc.so.2.14.1 => libcustcalc.so.2.14.1.0

we could simply link calc to libcalc.so and libcustcalc.so.

The impact of this might mean that calc could become unable if, for example. libcalc.so were symlinked to version 2.14.2.x and the calc binary were not similarly updated.

Using the hypothetical release set example above, linking a 2.14.1.0 version of calc binary to libcalc.so that was in-turn symlinked to libcalc.so.2.14.2.4 might produce bad results. One would need to update the calc binary as well as the what libcalc.so was symlinked to in order to achieve a stable production releases.

Comments and suggestions welcome, @zvezdochiot .

@lcn2 say:

In addition to this linking scheme:

"Slightly" different:

libcalc.so.2.14.1 => libcalc.so.2.14.1.0
libcalc.so.2.14 => libcalc.so.2.14.1
libcalc.so.2 => libcalc.so.2.14
libcalc.so => libcalc.so.2

@lcn2 say:

we could simply link calc to libcalc.so and libcustcalc.so.

Not! libcalc.so and libcustcalc.so are development links to check for the presence of a library regardless of version (dev-package). The binding is defined by -Wl,-soname,libcalc.so.${VERSION_MAJOR}: https://github.com/lcn2/calc/blob/3e4391e2afee0acd4eeece714adabe2d52295b4b/Makefile#L1526

@lcn2 say:

might produce bad results

If the library API changes, then VERSION_MAJOR is changed.

@lcn2 say:

In addition to this linking scheme:

"Slightly" different:

libcalc.so.2.14.1 => libcalc.so.2.14.1.0
libcalc.so.2.14 => libcalc.so.2.14.1
libcalc.so.2 => libcalc.so.2.14
libcalc.so => libcalc.so.2

We presume in general, both libraries should be so linked. So in general we would do:

libcalc.so.2.x.y => libcalc.so.2.x.y.z
libcalc.so.2.x => libcalc.so.2.x.y
libcalc.so.2 => libcalc.so.2.x
libcalc.so => libcalc.so.2
libcustcalc.so.2.x.y => libcustcalc.so.2.x.y.z
libcustcalc.so.2.x => libcustcalc.so.2.x.y
libcustcalc.so.2 => libcustcalc.so.2.x
libcustcalc.so => libcustcalc.so.2

@lcn2 say:

we could simply link calc to libcalc.so and libcustcalc.so.

Not! libcalc.so and libcustcalc.so are development links to check for the presence of a library regardless of version (dev-package). The binding is defined by -Wl,-soname,libcalc.so.${VERSION_MAJOR}:

https://github.com/lcn2/calc/blob/3e4391e2afee0acd4eeece714adabe2d52295b4b/Makefile#L1526

@lcn2 say:

might produce bad results

If the library API changes, then VERSION_MAJOR is changed.

There isn't a VERSION_MAJOR symbol, so we think you mean MAJOR_PATCH.

FYI: Here is a bit more info about calc version conventions:

The MAJOR_VER remains at 2. There are concepts for version 3 calc, but that is a long way off. One of the main reasons why MAJOR_VER might incremented is if fundamental calc data objects (such as when ZVALUE or NUMBER or COMPLEX need to change) that would cause an incompatibility with existing hardware accelerators that are using fundamental calc data objects.

The MINOR_VER changes when there are incompatible changes to the calc library or calc custom library. The MINOR_VER is currently at 14, but might change to 15 if we need to make a major change to the math engine. For example, when the way 0^x was evaluated, we changed MINOR_VER from 13 to 14.

The MAJOR_PATCH changes when there is an update to the calc library or calc custom library. For example, the MAJOR_PATCH might increment when there are new builtin functions available, or when there is a change to how existing builtin functions process arguments.

The MINOR_PATCH changes whenever there is any change in the released files of calc. For example, when the documentation changes, the MINOR_PATCH will increment. Moreover, when we are working towards a new production release, bug fix and improvement updates will cause MINOR_PATCH to increment.

We currently tie calc to the full 2.x.y.z version of libcalc and libcustcalc via Makefile variables (such as for Linux):

...
VERSION= 2.14.1.0
...
LIB_EXT= .so
LIB_EXT_VERSION= ${LIB_EXT}.${VERSION}
...
LIBCALC_SHLIB= -shared "-Wl,-soname,libcalc${LIB_EXT_VERSION}"
LIBCUSTCALC_SHLIB= -shared "-Wl,-soname,libcustcalc${LIB_EXT_VERSION}"

An important aspect of the calc version convention (as noted above) is that when the MINOR_PATCH changes, we would need to re-link calc. For example, if calc were to advance to version 2.14.2.0 calc would need to link to a new libraries. However this would not be strictly needed if calc were to advance to just calc version 2.14.1.1.

Using the Linux Makefile variables shown above, we might do this instead:

...
VERSION= 2.14.1.0
VER= 2.14.1
...
LIB_EXT= .so
LIB_EXT_VERSION= ${LIB_EXT}.${VER}
...
LIBCALC_SHLIB= -shared "-Wl,-soname,libcalc${LIB_EXT_VERSION}"
LIBCUSTCALC_SHLIB= -shared "-Wl,-soname,libcustcalc${LIB_EXT_VERSION}"

Instead if linking to libcalc.so.2.x.y.z and libcustcalc.so.2.x.y.z, we would link to just libcalc.so.2.x.y and libcustcalc.so.2.x.y.

If we made this change, then if calc version 2.14.1.1 were released the library calc links to would not change. However if calc version 2.14.2.0 were later released, the library calc links to would change.

Would that help / satisfy your request, @zvezdochiot ?

Hi @lcn2 .

No. You have some special requirements for versions. Standard build version for libraries:

VERSION_LIBRARY = $(VERSION_MAJOR).$(VERSION_MINOR).$(VERSION_RELEASE)

$(VERSION_MAJOR) defines API compatibility. But your seem to be different. :(

Hi @lcn2 .

No. You have some special requirements for versions. Standard build version for libraries:

VERSION_LIBRARY = $(VERSION_MAJOR).$(VERSION_MINOR).$(VERSION_RELEASE)

$(VERSION_MAJOR) defines API compatibility. But your seem to be different. :(

What you call $(VERSION_MAJOR) we call MAJOR_VER. What you call $(VERSION_MINOR) we call MINOR_VER. What you call $(VERSION_RELEASE) we call MAJOR_PATCH.

The term API compatibility depends on what is being considered on the other side of the library.

For example, in terms of hardware (such as hardware based accelerators), the so called "API compatibility" relies on MAJOR_VER which you call $(VERSION_MAJOR).

In terms of new functions calls to the calc library (such as new calc builtin functions), the so called "API compatibility" relies on MINOR_VER which you call $(VERSION_MINOR).

In terms of changes to the function call interface to the calc library (such as mentioned in the LINK LIBRARY in help files for functions), the so called "API compatibility" relies on MAJOR_PATCH which you call $(VERSION_RELEASE).

So we have 3 levels of API compatibility:

1. hardware accelerators - MAJOR_VER
2. builtin calc functions - MINOR_VER
3. programatic function calls to calc library - MAJOR_PATCH

In terms of the calc library API compatibility we use MAJOR_PATCH (which you call $(VERSION_RELEASE).

If we understand correctly what would prefer: consider the output of ldd calc, which currently is:

$ ldd ./calc
        ...
	libcalc.so.2.14.1.0 => /lib/libcalc.so.2.14.1.0 (0x00007ff712a55000)
	libcustcalc.so.2.14.1.0 => /lib/libcustcalc.so.2.14.1.0 (0x00007ff71284f000)
        ...

If we understand what you are suggesting, we need to the above to:

$ ldd ./calc
        ...
	libcalc.so.2 => /lib/libcalc.so.2 (0x00007ff712a55000)
	libcustcalc.so.2 => /lib/libcustcalc.so.2 (0x00007ff71284f000)
        ...

• [ ] The above would assume that the following symlinks:

libcalc.so.2.14.1 is symlinked to libcalc.so.2.14.1.0
libcalc.so.2.14 is symlinked to libcalc.so.2.14.1
libcalc.so.2 is symlinked to libcalc.so.2.14
libcalc.so is symlinked to libcalc.so.2
libcustcalc.so.2.14.1 is symlinked to libcustcalc.so.2.14.1.0
libcustcalc.so.2.14 is symlinked to libcustcalc.so.2.14.1
libcustcalc.so.2 is symlinked to libcustcalc.so.2.14
libcustcalc.so is symlinked to libcustcalc.so.2

Would that satisfy what you are requesting, @zvezdochiot ?

We reopened this case, @zvezdochiot and revised the above comment 1190638239, because we think we might be able to satisfy your request.

let us know what you think of the comment 1190638239 proposal, if you please.

We we have seen no reply since 2022 Jul 20. If you, @zvezdochiot, wish for us to address this issue via the https://github.com/lcn2/calc/issues/56#issuecomment-1190638239 proposal, please consider reopening this request.