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.
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. 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? 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"... 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. Terrence Miller wrote: > Using libraries with a C++ interface is even more dangerous than John > describes. If the include file which specifies the library interface is > written to allow inlining of function calls, programs using the library > become sensitive to minute details of the library implementation (even > if the compiler is unchanged). > > IMO any C++ interface to a shared library should be consolidation > private so that library and clients can be recompiled together. > Having C wrappers for the library entry points (that we ship) would > satisfy that requirement. > > > John Plocher wrote: >> Laszlo (Laca) Peter wrote: >>> Given that these are c++ libs, is it acceptable to ship >>> duplicate copies built with g++ (/usr/sfw/bin/g++) and if >>> so, where should they be installed? >> The problem is that there is no ABI standard for g++, >> so you would need to create and ship different versions >> of the libs for each and every release of g++ that [exists, >> we ship, we choose to support, pick one]. When you >> consider that the g++ ABI has frequently changed in patches >> and bugfixes for g++, this doesn't leave us with any >> reasonable choice - we can't do "all", tying *every* C++ >> app to the g++ patch release schedule doesn't scale, and >> if we only pick one or a couple of releases, they will >> tend to be not the ones customers want...) >> >> As long as someone has all the source code for libs and apps >> (aka gentoo), the g++ abi doesn't really matter, as it is >> possible to compile a consistent set of things. Once you >> provide precompiled g++ libs, you are tied to a specific >> patch level of the g++ compiler tools suite. >> >> Because of this, we have historically said no to non-studio >> C++ libs, unless those libs only exported "C" ABIs (via >> extern "C" constructs). >> >> -John >>
