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.
     Jack

------------------------------------------------------------------------------
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
Fink-devel@lists.sourceforge.net
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

Reply via email to