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
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.
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. The graphite support in gcc will have been built against
the ppl headers from a different soversion than those used to build
cloog.
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.
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
[email protected]
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel
