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 > -------------- next part -------------- A non-text attachment was scrubbed... Name: Terrence.Miller.vcf Type: text/x-vcard Size: 211 bytes Desc: not available URL: <http://mail.opensolaris.org/pipermail/opensolaris-arc/attachments/20080206/8a070e9f/attachment.vcf>
