Release GiNaC 1.5.4

[Jens Vollinga]

Hi everybody,

GiNaC 1.5.4 is out and available. The changes are:

* Default parser now can again read in user defined classes.
* Add mul::info() and add::info() support for numeric info_flags
   (GiNaC now can detect that the sum or product of a number of
   positive expressions is again a positive expression).
* Fixed cast that caused compile error on 64bit machines.
* Fixed incorrect uses of STL iterators.
* Removed subdirectory debian.
* Output LaTeX-symbols using \mathrm, instead of \mbox.

As always, this release can be downloaded from

http://www.ginac.de/Download.html

Best wishes,
Jens
_______________________________________________
GiNaC-devel mailing list
GiNaC-devel@...
https://www.cebix.net/mailman/listinfo/ginac-devel

[Richard B. Kreckel]

Hi Jens,

Jens Vollinga wrote:

> GiNaC 1.5.4 is out and available. The changes are:
>
> * Default parser now can again read in user defined classes.
> * Add mul::info() and add::info() support for numeric info_flags
>   (GiNaC now can detect that the sum or product of a number of
>   positive expressions is again a positive expression).
> * Fixed cast that caused compile error on 64bit machines.
> * Fixed incorrect uses of STL iterators.
> * Removed subdirectory debian.
> * Output LaTeX-symbols using \mathrm, instead of \mbox.

* A new soname, making it unsuitable as drop-in replacement for
   GiNaC-1.5.[0-3] for distributions.  :-(

Methinks, my patch f2f67dde5c9caca is screwy and made you screw up the
soname of libtool versioning.

Rats! I was lucky to finally have arrived at a crystal clear
prescription in configure.ac and now it turns out to be wrong.

   -richy.
--
Richard B. Kreckel
<http://www.ginac.de/~kreckel/>
_______________________________________________
GiNaC-devel mailing list
GiNaC-devel@...
https://www.cebix.net/mailman/listinfo/ginac-devel

[Richard B. Kreckel]

Hi!

Richard B. Kreckel wrote:
> * A new soname, making it unsuitable as drop-in replacement for
>   GiNaC-1.5.[0-3] for distributions.  :-(
>
> Methinks, my patch f2f67dde5c9caca is screwy and made you screw up the
> soname of libtool versioning.
>
> Rats! I was lucky to finally have arrived at a crystal clear
> prescription in configure.ac and now it turns out to be wrong.

Oh, I think I know what's messed up! The text in configure.ac is
correct, but when we don't use the age feature, we have only two
situations: A) the interface is the same as before and B) the interface
was extended by functions/classes.

Normally, case A would be ++revision. Case B would be ++current, ++age,
and revision=0. So we always have age==current. But the way
LT_VERSION_INFO in configure.ac is assigned, age is pinned at 0! It
should be pinned at age, instead.

So, this would be the correct fix:

--- a/configure.ac
+++ b/configure.ac
@@ -58,8 +58,9 @@ AC_DEFINE_UNQUOTED(ARCHIVE_VERSION, $ARCHIVE_VERSION,
[Current GiNaC archive fil
  AC_DEFINE_UNQUOTED(ARCHIVE_AGE, $ARCHIVE_AGE, [GiNaC archive file
version age])

  dnl libtool versioning (We don't use libtool's age numbering since we
promise
-dnl to keep the binary interface compatible if only ginac_micro_version
changes.)
-LT_VERSION_INFO="ginac_lt_current:ginac_lt_revision:0"
+dnl to keep the binary interface compatible if only ginac_micro_version
changes.
+dnl In effect, age is pinned to current.)
+LT_VERSION_INFO="ginac_lt_current:ginac_lt_revision:ginac_lt_current"
  LT_RELEASE="ginac_release"

  AC_SUBST(LT_VERSION_INFO)

Indeed, it leads to libginac-1.5.so.0.1.0 with soname libginac-1.5.so.0.

   -richy.
--
Richard B. Kreckel
<http://www.ginac.de/~kreckel/>
_______________________________________________
GiNaC-devel mailing list
GiNaC-devel@...
https://www.cebix.net/mailman/listinfo/ginac-devel