> I was talking binary compatibility, while it sounds like you're talking source > compatibility. > > If you can build a library with either Studio cc or gcc, then users of both > can link their programs against it, you don't need to provide different > versions for each compiler as you must do with C++. (And technically it's > worse with C++, since there's multiple versions of the ABI for each, but > for now, I believe the C++98 standard version of each is currently the only > one worth worrying about until the C++0x versions take hold, and the pre-98 > versions can be ignored.)
I'm talking about both, in this sense: some open source software written in C++ will presumably only compile (without significant changes) using the GNU compiler suite, because that software depends on features not (compatibly) present in the Studio suite. If that software depends on C++ libraries, then because of the binary incompatibility between C++ APIs for gcc vs Studio, that means all its C++ dependencies also have to be compiled with gcc, even if one also has a Studio compatible version of them to satisfy other needs. That would be the case even if the library source code was compatible with both compilers. I guess the main thing I'm saying is that dependencies can get ugly as it is (not that I know that it uses anything in C++, but taking as an example pidgin, it links to over _50_ libraries!). With such proliferation of libraries, and two different ABIs for C++ libraries, I'd just about count on it that there are going to be situations where one will need them compiled with both compilers. Or with multiple versions of a library to accomodate apps with incompatible dependencies. Or both. To an end user, what makes a distro different from a disparate collection of parts is that _everything_works_; all dependencies have been resolved (while at the same time having only those multiple versions or ABIs or whatever of dependencies as are needed). Realizing also, that there's a definite choice to be made in terms of being able to update individual apps relatively separately vs having less versions of dependencies around. Both can be legitimate choices - smaller disk and memory footprint vs greater freedom to keep apps current. That means that some sort of _design_ and testing probably has to apply to the distro as a whole, packaging has to correctly and maintainably identify dependencies, etc. Which is why all this talk like the ideal distro should match Debian, Fedora, or Ubuntu's package count makes me crazy. Better to prioritize and go for overall quality, IMO. Get a good handle on what it takes to do a really excellent job of integrating packages (maintainably) before going crazy on making the number look good. Not only does that apply to the individual user, who doesn't want to be be fixing things the distro creator should have done right. It applies to enterprise level use as well, where updates may well be automated, so there'd better be darn few surprises, or the phone will ring off the hook when an update is pushed out. _______________________________________________ OpenIndiana-discuss mailing list [email protected] http://openindiana.org/mailman/listinfo/openindiana-discuss
