On Sat, 2006-03-04 at 21:50 -0300, Pedro Lamarão wrote: > Nicholas Miell wrote: > > [SNIP] > > > Nice to see that somebody is finally trying to solve the problem, > > instead of just letting the users suffer. Maybe C++ will actually be a > > viable language for library development one day soon. > > C++ is excellent for library development. You have failed to consider what happens when multiple objects link to different ABI-incompatible versions of libstdc++. In such a situation, ELF symbol resolution rules cause all the libstdc++ symbols to resolve to the first instance of the library loaded (typically the version of libstdc++ used by the main application). If vtable layout has changed, object size or layout has changed, or some implementation detail assumed by inlined libstdc++ functions has changed, things blow up messily. This will happen even if the main application doesn't actually use the STL, because it has to link to libstdc++ anyway to get the runtime support necessary for C++ to function. (This runtime support is actually part of libsupc++ -- which has had a stable ABI -- but you can't link to libsupc++ separately in the dynamic case.) ELF symbol versioning is supposed to help with this, but apparently it doesn't (for reasons that were never really made clear). It certainly won't help in the case where STL objects are involved in the public library API. As such, the only reliable way to use C++ on Linux is to never actually use any of the STL. This isn't something you can guarantee and decreases the benefits of using C++ in the first place. (And if any of this happens to be wrong, please correct me!) -- Nicholas Miell <nmiell@xxxxxxxxxxx> -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
