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?
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.
Jakub
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"?
Or else add -Bdirect and/or -Bgroup support to glibc's rtld.
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. 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 use 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.
Jakub
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 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.[1]
C++ libraries present difficulties to distributors of precompiled systems in an environment where users need, for some random reason, to use the latest.
g++ 3.3 is still available, and g++ 3.4 is still being maintained. You don't want your system to break ABI? Don't break ABI in *your* system, then.[2] This is the free software world.
[2] I don't remember Red Hat / Fedora ever upgrading GCC like that for a given system version. But maybe I just don't remember much.
-- Pedro Lamarão
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 wrote:
C++ is excellent for library development.
You have failed to consider what happens when multiple objects link to different ABI-incompatible versions of libstdc++.
I have not. Of course there are problems with linking together objects which themselves are linked against incompatible versions of the same library.
BUT, as I said, this is not a problem simply because libraries break ABI, this is a problem because systems administrators and/or users, for some random reason, decide to use the latest.
Why are you linking new objects against the latest when already present, necessary, objects are linked against something older?
Are we talking about "absolute" requirements like some new software you must have that is not compatible with your current system? Oops, not compatible with your current system.
Are you upgrading your system compiler, together with your system libraries, to a newer, ABI breaking, version? Oops, not compatible with your current system.
Are you doing it just because newest is best? Whoa.
Are you doing it without even noticing? Whoa. Why are you compiling stuff again?
This is the free software world. If you were being forced to upgrade to ABI breaking versions, because, say, your commercial vendor says so, I'd understand your woes. But you're not. The source for older free software is available for as long as we're competent to keep the storage running. I never heard of relevant free software being lost forever for any reason.
On Sun, 2006-03-05 at 00:20 -0300, Pedro Lamarão wrote:
Nicholas Miell wrote:
C++ is excellent for library development.
You have failed to consider what happens when multiple objects link to different ABI-incompatible versions of libstdc++.
I have not. Of course there are problems with linking together objects which themselves are linked against incompatible versions of the same library.
I shouldn't have to care, and incompatible versions of the same library shouldn't exist.
BUT, as I said, this is not a problem simply because libraries break ABI, this is a problem because systems administrators and/or users, for some random reason, decide to use the latest.
Or perhaps they upgraded their OS.
Why are you linking new objects against the latest when already present, necessary, objects are linked against something older?
I'm not. I'm linking them against the system-supplied library chosen by the compiler. Of course, I can't actually distribute this object, because my end users might have other objects linked against newer or older versions of libstdc++.
Are we talking about "absolute" requirements like some new software you must have that is not compatible with your current system? Oops, not compatible with your current system.
Are you upgrading your system compiler, together with your system libraries, to a newer, ABI breaking, version? Oops, not compatible with your current system.
Are you doing it just because newest is best? Whoa.
Are you doing it without even noticing? Whoa. Why are you compiling stuff again?
This is the free software world. If you were being forced to upgrade to ABI breaking versions, because, say, your commercial vendor says so, I'd understand your woes. But you're not. The source for older free software is available for as long as we're competent to keep the storage running. I never heard of relevant free software being lost forever for any reason.
Ah, so you think that N different versions of program compiled for FC 4, FC 3, FC 2, FC 1, RHEL 4, RHEL 3, CentOS 4, CentOS 3, SLES 9, NLD 9, SuSE Linux 10, Debian etch, Debian 3.1, Ubuntu 5.10, Ubuntu dapper drake, Mandriva 2006, and Slackware 10.2 is a good thing? (And that's just the big distros...)
devel@lists.stg.fedoraproject.org
-
Jakub Jelinek -
Neal Becker -
Nicholas Miell -
Pedro Lamarão