[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: libstdc++-so7 info?



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 comcast net>


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]