On Jun 10, 2010, at 09:03, Jack Howarth wrote: > On Thu, Jun 10, 2010 at 03:48:19PM +0200, Vincent Lefevre wrote: >> FYI, GNU MPFR 3.0.0 has just been released, but it is normal that >> I haven't updated the port yet: this new version is *not* binary >> compitible with the previous ones, and there are some dependencies >> that must be resolved first. For instance, the current Math::MPFR >> Perl module is not compatible with MPFR 3; its author will upload >> a new version to CPAN soon. >> >> All ports that depend on MPFR will need to be rebuilt (otherwise >> you'll get a failure because libmpfr.1.dylib cannot be found). > > This is one of the major defects in the current MacPorts implementation > IMHO. There really ought to be a way to have co-existing mpfr-shlibs > packages for 2.x and 3.x but conflicting mpfr packages for building > programs against. We have exactly the same issue with molmol in > MacPorts. It is incompatible with the current openmotif 2.3.x releases and > needs co-existing openmotif-shlibs packages for 2.2.x and 2.3.x so > that molmol can be built and run against openmotif 2.2.x.
I guess I don't understand the distinction you're making. What's the problem with the strategy we've followed thus far, which would be for mpfr to be updated to version 3.0.0 and a new port mpfr2 to be created for the last version of mpfr 2.x and to update ports to use mpfr2 if needed? Or alternately for mpfr to stay at version 2 and a new port mpfr3 to be created? These strategies seem to have served us well so far. _______________________________________________ macports-dev mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
