Hi Jack,

Sorry for replying so late _ got a bit swamped by other things..

On 08 Aug 2010, at 15:02, Jack Howarth wrote:

> On Fri, Aug 06, 2010 at 07:44:05PM +0200, Jean-François Mertens wrote:
>> 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 .. (?)
>> ....
>> I can see no runtime problems, since things 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,
>   You're neglecting the fact that gcc loads the ppl headers via the
> cloog headers....

That was exactly my question in the first paragraph quoted above.
Extracted a build-dir to check, and indeed, EVERY include for
cloog.h is followed (preceded in the case of graphite_ppl.c)
immediately by one of ppl_c.h...
And I assume that the multiple-inclusion guards in the 2 ppl versions
are the same.
Then, in effect, it is as if there was only an include for cloog.h
in all files except for graphite_ppl.c...
It might still be designed to work well with 2 different versions of  
ppl,
but I fully agree with you that it looks much too iffy to play on
without a full understanding.

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

Reply via email to