On Wed, 2006-02-22 at 15:18 -0500, Jakub Jelinek wrote: > On Wed, Feb 22, 2006 at 11:40:20AM -0800, Nicholas Miell wrote: > > On Wed, 2006-02-22 at 07:09 -0500, Jakub Jelinek wrote: > > > On Wed, Feb 22, 2006 at 07:06:45AM -0500, Neal Becker wrote: > > > > I noticed the libstdc++-so7 preview, but I haven't been able to find any > > > > information that summarizes what is new, compared with the current > > > > libstdc++. Any pointers? > > > > > > It is only included for scim purposes, please don't use it for anything > > > else. It contains various ABI breaking experimental STL changes that > > > are not applicable to libstdc++.so.6. > > > > > > > Oh great, they're breaking the ABI again!? When will those idiots > > learn... > > > > How about Fedora stops including all new versions of libstdc++ until the > > maintainers manage to wrap their tiny little minds around the concept of > > a "stable ABI"? > > Please don't insult people who know about C++ ABI stuff far more than > you apparently do. Yeah, that was kind of harsh. This is one of my pet peeves. > There are several C++ ABI bugs both on the compiler > side (things you currently get with -fabi-version=0, PR22488 etc.) > and several things in the STL land are simply not doable without > ABI break, backwards compatibility in C++ world is a few orders of magnitude > harder in C++ than in C. G++ 3.4/4.0/4.1 have C++ ABI compatibility > and nobody said yet to my knowledge if 4.2 will or won't be compatible, > libstdc++so7 is simply a playground for things that aren't doable > without ABI break (similarly to -fabi-version=0). If/when it is decided > to do an ABI break, all the stuff in there can be used. > > >From my own experience when I was doing the long double switch also in > libstdc++, aiming for libstdc++.so.6 compatibility with both DFmode > and TFmode long double, maintaining C++ ABI compatibility is a nightmare, > you basically can't use symbol versioning and due to inheritance, inlining > and ODR things are really hard to do. > > We included this in Fedora, because SCIM IM modules are written in C++ > and as they need to be loaded into arbitrary Gtk (and KDE) applications, > there is a big problem if the application uses some older libstdc++.so. > This can be solved only with dlmopen (but then, SCIM IM modules us > like 40 or 50 shared library dependencies, so dlmopen isn't really a > good idea), or by namespace versioning, which is one of the things > libstdc++so7 has. 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. (Also re: dlmopen & namespace versioning -- couldn't the same thing be accomplished using linker groups? -- assuming glibc supported them) -- Nicholas Miell <nmiell@xxxxxxxxxxx> -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
