gcc version mismatches

[Ryan Schmidt]

On Nov 16, 2011, at 21:56, Kyle Husmann wrote:
> On Wed, Nov 16, 2011 at 7:44 PM, Ryan Schmidt wrote:
>> That sounds like a possibility. But my understand was that *usually* the mismatched stdc library versions aren't a problem, but that in some rare cases it is.
> 
> I think if apple shipped with a gnu stdc, everything would be just
> fine because gnu provides backwards binary compatibility. I don't
> think this is necessarily the case when mixing gnu stdc with apple's
> stdc, which puts us into undefined-behavior-land.
> 
> So, while the problem might rarely manifest, I think it's definitely a
> problem. (And especially a problem for scientific libs that scientists
> trust to have very well defined behavior)

Ok. What solution are you advocating?

It sounds like you're saying we should never mix Apple gcc compilers with fsf gcc compilers. Some very small number of ports require a newer gcc than Apple provides, hence the fsf gcc is the only option. What should we do in that case: force the user to rebuild all ports?

Is it only Apple gcc that's a problem? If so, does that mean the problem is already resolved when using Xcode 4 on Lion and Snow Leopard, where the default compiler is not gcc, but Apple llvm-gcc or Apple clang (depending on Xcode version)?

Is Apple clang vs. plain clang also a problem?

The reason many ports depend on a gcc port is not because they need a newer C or C++ compiler, but because they need a Fortran compiler, which Apple doesn't provide at all. Many of these ports still happen to switch to using the C and C++ compiler corresponding to that Fortran compiler they need, because it's easy to do so (a single configure.compiler directive to switch the entire compiler collection). I don't know if we can mix and match fsf gcc Fortran compiler plus system C and C++ compiler; if we can, would that solve the problem? Or would code generated with Fortran also be vulnerable?