On 06 Aug 2010, at 18:24, Jack Howarth wrote: > On Fri, Aug 06, 2010 at 05:35:55PM +0200, Jean-François Mertens wrote: >> >> On 06 Aug 2010, at 17:32, Jean-François Mertens wrote: >> >>> 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). >> >> More explicity, for cloog it can be a plain version update, and >> things >> that linked to >> the old version should continue linking well with the new, w/o >> rebuilding. > > JF, > Apparently both Debian and Fedora have been building gcc with -ldl > and thus don't have explicit linkages in the gcc binaries to libppl, > libppl_c and libcloog. However they still end up with the same issue. Instead of the 'however', I would see this as a possible source of their problems: they don't have the protection of linking with an install_name, i.e., with a full path. > If you build gcc with a libcloog and ppl 0.10.2, the ppl headers > (and interfaces) will be from ppl 0.10.2 whereas if you later upgrade > cloog to a version built against ppl 0.11 your will get a header > mismatch. Right _ I see now that cloog.h unconditionally includes ppl_c.h (indirectly); so if in some compilations of the build of gcc, headers from both ppl and cloog are called, that might be a source of trouble. I guess you know that there are such compilations .. (?) > The graphite support in gcc will have been built against > the ppl headers from a different soversion than those used to build > cloog. There is see no problem (except for the small runtime overhead of having 2 ppl libs in memory rather than just 1). > The gcc developers seem to agree that gcc needs a version check > for the ppl in use. However I would argue that this merits a new > cloog call to properly do it (which in turn allows for a valid > soversion bump in cloog). In the extreme, both gcc and cloog could > embed the version of ppl used to build them. When graphite is used > in gcc, it should check the run-time version of ppl against the > version gcc was built with and if coherent pass that to cloog > which does the same and then checks for coherency against gcc's > ppl version.
I can see no runtime problems, since thnigs are linked by install_name; even in the same binary, you could conceivably have 2 different symbols coming resp. from libfoo1.dylib and libfoo2.dylib. But here gcc would just link with cloog and the ppl it was built with, while cloog itself will link against whatever ppl it was built with. That is no problem. JF ------------------------------------------------------------------------------ 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
