On 9/4/07, Ken Raeburn <raeburn@xxxxxxxxxxx> wrote: > On Sep 4, 2007, at 13:26, Lawrence Crowl wrote: > > On 8/31/07, Ken Raeburn <raeburn@xxxxxxxxxxx> wrote: > >> Is the usual procedure, then, to just require that the application > >> builder consistently use the same compiler implementation for > >> everything? > > > > Yes, though this is not as onerous as you might think. > > That one I would think would be relatively easy. It's the vendor- > supplied libraries case I'm concerned about. Yes, but they use the reference compiler (or a close approximation). > > >> This would be particularly annoying if the library in > >> question were being provided by the OS vendor, and not always > >> downloaded and built by the application builder. > > > > On systems with strong binary compatibility guarantees, shipping > > binaries with an agreed upon base compiler is not terribly difficult. > > Generally, there is one compiler associated with the OS that serves > > as the reference compiler, and all others must conform. On > > Windows, that compiler is Microsoft's. On Solaris, that compiler > > is Sun's. On HPUX, that compiler is HP's. > > If exceptions and such are as much of a problem as it sounds, I guess > they aren't doing very well at conforming? I think I was unclear. Avoiding exceptions is only necessary if you wish to avoid any dependence on the C++ run-time library. If the dependence is acceptable, then exceptions are fine as long as you use the stable reference compiler. > > On Linux, the binary > > story is not as strong, but the compiler is GNU's. > > I remember there being quite a mess around the pre-gcc-3 days because > of ABI changes in the GNU compilers, though I don't know if it > affected all libraries using C++ at all, or just those exposing use > of C++ in their APIs. Just the sort of thing I'd want to avoid.... Certainly the latter, but the former is possible with unstable C++ runtime libraries. -- Lawrence Crowl
