libstdc++.so.x issue
Shen Wu
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.
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.
Anyone know what is the reason GNU doing this?
What is the positioning of the major Linux vendors and GNU on this?
Do they expect users rebuild their applications very time they update the
OS/GCC?
Where can I find the information on this?
Thanks
Shen
Joe Durusau
I suspect that you may be seeing a side effect of the
fact that each version of a C++ compiler is supposed to generate
code that is incompatible with every other version. I have
been told that the C++ standard requires that the name mangleing
feature be unique to each compiler. I have never verified this
myself, so you might want to check out the standard, if you can
get at a copy.
Speaking only for myself,
Joe Durusau
Shen Wu
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
André Pönitz
> I suspect that you may be seeing a side effect of the
> fact that each version of a C++ compiler is supposed to generate
> code that is incompatible with every other version. I have
> been told that the C++ standard requires that the name mangleing
> feature be unique to each compiler.
I've never seen that, and I actually doubt the value of such an
requirement. Fact is, there are many incompatible ways used for name
mangling, so chances are high that using different compilers (or even
versions of the same compiler) breaks things.
Andre'
--
Those who desire to give up Freedom in order to gain Security,
will not have, nor do they deserve, either one. (T. Jefferson)