On 06 Aug 2010, at 15:52, Jack Howarth wrote: > I would be interested in the general consensus on > the following. A new recommended update to ppl, > version 0.11, was released this week. Currently > cloog won't build against this due to a version > check which will soon be adjusted to allow this. > However, allowing cloog to build with the same > soversion against either ppl-0.10.x or ppl-0.11 > will introduce shared library coherency problems > with the gcc4x packages that build against cloog > and ppl. > My first instinct was to create a conflicting > ppl2 package for ppl v0.11 which has ppl2-shlibs > split-off which can co-exist with ppl2-shlibs > and then rebuild cloog against ppl2. I immediately > discovered however that legacy builds of gcc4x > would end up indirectly linked to different ppl > versions... > > [MacPro:gcc/x86_64-apple-darwin10.4.0/4.5.1] howarth% otool -L f951 > f951: > /sw/lib/libintl.8.dylib (compatibility version 9.0.0, current > version 9.2.0) > /sw/lib/libiconv.2.dylib (compatibility version 7.0.0, current > version 7.0.0) > /sw/lib/libcloog.0.dylib (compatibility version 1.0.0, current > version 1.0.0) > /sw/lib/libppl_c.2.dylib (compatibility version 4.0.0, current > version 4.0.0) > /sw/lib/libppl.7.dylib (compatibility version 9.0.0, current > version 9.0.0) > /sw/lib/libgmpxx.4.dylib (compatibility version 6.0.0, current > version 6.2.0) > /sw/lib/libmpc.2.dylib (compatibility version 3.0.0, current > version 3.0.0) > /sw/lib/libmpfr.1.dylib (compatibility version 4.0.0, current > version 4.2.0) > /sw/lib/libgmp.3.dylib (compatibility version 9.0.0, current > version 9.2.0) > /usr/lib/libz.1.dylib (compatibility version 1.0.0, current version > 1.2.3) > /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current > version 438.0.0) > /sw/lib/gcc4.5/lib/libgcc_s.1.dylib (compatibility version 1.0.0, > current version 1.0.0) > /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current > version 125.2.0) > > [MacPro:gcc/x86_64-apple-darwin10.4.0/4.5.1] howarth% otool -L /sw/ > lib/libcloog.0.dylib > /sw/lib/libcloog.0.dylib: > /sw/lib/libcloog.0.dylib (compatibility version 1.0.0, current > version 1.0.0) > /sw/lib/libgmp.3.dylib (compatibility version 9.0.0, current > version 9.2.0) > /sw/lib/libppl_c.4.dylib (compatibility version 5.0.0, current > version 5.0.0) > /sw/lib/libppl.9.dylib (compatibility version 10.0.0, current > version 10.0.0) > /sw/lib/libgmpxx.4.dylib (compatibility version 6.0.0, current > version 6.2.0) > > I am trying to convince upstream to take the slightly non-conventional > approach of a cloog-0.16 release which requires ppl-0.11 or later to > build > and contains a soversion bump. If this is rejected, we will be faced > with > a less than optimal upgrade path as all gcc4x packages built against > cloog/ppl will have to be forcibly upgraded to build against > ppl-0.11 and > cloog built with the same. > Any advice on this is welcome. My main concern is that if the > soversion bump > is rejected, we will also have to worry about stray cloog.0.dylib's > in /usr/local/lib, etc > built against an older ppl.
As long a cloog's own install_name doesn't change, I see in principle no problem in creating a new ppl pkg for the new version (since there the install name does change), and to upgrade (independently, ie, whenever you want) cloog and one or more gccxy pkgs to use the new ppl (and/or) the updated cloog. I.e., cloog and gccxy using diferent ppl's should not be a problem per se (as long as you can prevent cloog's flags for ppl to come before gcc's own flags in the build of gcc; but that's at worst a flag-ordering problem). Or did I miss something in your message ? Jean-Francois ------------------------------------------------------------------------------ This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev _______________________________________________ Fink-devel mailing list [email protected] http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
