On Tuesday 20 October 2009 14:45:05 Dan Grayson wrote: > 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. > It may work on other OS's as well , I dont know that much about them. You could also search the library as a binary file and test for the existence of strings in it like mpir_version.
> Thanks! > > On Oct 19, 10:35 pm, Jason Moxham <[email protected]> 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 [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en -~----------~----~----~----~------~----~------~--~---
