That's a good thought, but returning 4.3.0-mpir as the gmp version number would be less likely to break routines that compare version numbers than returning mpir-4.3.0, especially when comparing to something like 4.2.1 that doesn't have the extra characters. There are lots of packages out there that append such things as "a" or "alpha1" or "beta" occasionally, so generic routines for comparison of version numbers would be tailored for such things.
Loading a second copy of the library seems of marginal utility if it only works on some OS's. Thanks! On Oct 19, 10:35 pm, Jason Moxham <ja...@njkfrudils.plus.com> wrote: > We need something that gmp and mpir have but is different , the only thing is > the version number but it is coded as just a number 4.3.0 etc , if is was > encoded as gmp-4.3.0 then we could use mpir-1.3.0 and all would be good. We > can not change the gmp version number as many/most? programs test for this and > fail if it is not high enough. > > In Linux you could dynamically load a second copy of the library and test for > the existence of mpir_version. I think? ... --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "mpir-devel" group. To post to this group, send email to mpir-devel@googlegroups.com To unsubscribe from this group, send email to mpir-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en -~----------~----~----~----~------~----~------~--~---
