libstdc++.so.x issue

[Phil Edwards]

On Tue, Nov 19, 2002 at 11:42:50AM -0500, Shen Wu wrote:
> Hi,
> 
> We have a SDK type of application using C++ and built in gcc/g++. We provided *.so to our customers so that they can link their applications with it. We noticed that gcc standard library so file (libstdc++.so.x) keeps changing the version number. In gcc 3.0.4 it is libstdc++.so.3, in gcc 3.1 it is libstdc++.so.4 and now in gcc 3.2 it becomes libstdc++.so.5. Every time when a new version of gcc comes out, we have to rebuild our SDK. Otherwise, our SDK will not work for the machine with new gcc installed.

Yes.

> In term of glibc, the Linux vendors and GNU always do libc.so.6 -> libc-2.x.x.so. Therefore we do not have to rebuild our application as long as the new glibc backward compatible.

Yes.

> Anyone know what is the reason GNU doing this? 

Because the new libstdc++ is /not/ backwards compatible.  If it were, the
number wouldn't change.

> What is the positioning of the major Linux vendors and GNU on this? 

What I just said.

> Do they expect users rebuild their applications very time they update the OS/GCC?

If they want to take advantage of the new code, yet.  Vendors have methods
already in place for dealing with this.  Usually they simply provide all
the versions of the library, so that existing binaries continue to run.

There's nothing unique to libstdc++ about this.  Every other shared library
falls under the same consideration.

> Where can I find the information on this?

The mailing list archives at http://gcc.gnu.org/

-- 
I would therefore like to posit that computing's central challenge, viz. "How
not to make a mess of it," has /not/ been met.
                                                 - Edsger Dijkstra, 1930-2002