6:06 a.m.
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?
6:09 a.m.
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
1:40 p.m.
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.
--
Nicholas Miell <nmiell(a)comcast.net>
2:18 p.m.
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
3:02 p.m.
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(a)comcast.net>
6:50 p.m.
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.
[1] http://www.boost.org/
[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
8:10 p.m.
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(a)comcast.net>
9:20 p.m.
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.
10:36 p.m.
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...)
--
Nicholas Miell <nmiell(a)comcast.net>
6626
days inactive
6637
days old
8 comments
4 participants
participants (4)
-
Jakub Jelinek -
Neal Becker -
Nicholas Miell -
Pedro Lamarão