Darren Kenny wrote:
> The main benefit of having libraries in a public location is that people will
> use them - while these libraries are dependencies of some apps, they are also
> very useful for more rapid desktop development - making something 
> Consolidation
> Private really defeats this purpose.
> 

Agreed.... but we need to actually figure out how to deliver a working
build 85 if code in the SFW gate is built against build 84 JDS bits, and
JDS revs and delivers an incompatible version of a needed library in
build 85.

Cross consolidation flag days are a real PITA right now.

> I think we need to get away from the idea of Consolidations a bit, since
> OpenSolaris really breaks down these barriers and I think it would be pity to
> raise them again out there.
> 
> We really need to get C++ sorted for Solaris/OpenSolaris - we all use a CBE 
> for
> Solaris - and OpenSolaris AFAIK - could we not just ensure that at least this
> works for people out of the box, clearly stating the C++ compiler to use.

Here's the problem: some open source C++ will only compile w/ gcc. Do we
prevent people from compiling any apps that link w/ that library
with Studio?  Or do we ship two versions of each C++ library?

If we ship both, where do they go?  How does the linker choose the right 
one?

> 
> Is there some way that the compiler and linker could work together to flag a
> possible issue at run-time of the app and libs version of C++ compiler don't 
> match?
> 
Generally, it doesn't link at all; the error messages aren't obvious, 
however.

> It would actually be easier if the C++ compiler was simply there by default
> after installation so that there is less risk of someone installing the "wrong
> one"...
> 

g++ is; we're working on CC. IPS will help a lot, since you'll be able 
to grab the right compilers and install them on a system w/

pkg install gcc

This doesn't deal with the problem of different apps needing different
revs of the compilers, but at least that's a little rarer problem aside
from things such as wine.

> At least with OpenSolaris using IPS and a "blessed repository" it's more 
> likely
> that everything could be synchronised since if you bump the version of the
> compiler all libraries could be rebuilt with the version too - this is 
> actually
> more difficult for Solaris...
> 
> Darren.

The issue of reving the compilers is that we use them to build the 
kernel, and bugs in kernels are generally mnoticable, aggravating and 
serious.  The amount of testing required to shake out new versions of
compilers for ON is substantial; we've never been able to build a 
working kernel w/ an FCS compiler that I know of.... we always have
needed various bugs fixed...

The implication that the repository would handle the synchronization
problem pre-supposes that everything in the repository is built at once,
or at least staged.  This is not at all necessarily the case....

- Bart

Bart Smaalders                  Solaris Kernel Performance
barts at cyber.eng.sun.com              http://blogs.sun.com/barts

Reply via email to