shared libraries version

shared libraries version

[BeefStu BeefStu]

I have sample c++ program, which I am compiling (see steps below) onSolaris 
2.8, which uses the following version of g++.

/usr/local/bin/GNU/bin/g++ -c ./test.cpp -o test.o
/usr/local/bin/GNU/bin/g++ -g test.o -o test


/usr/local/bin/GNU/bin/g++ -v
Reading specs from 
/usr/local/bin/GNU/lib/gcc-lib/sparc-sun-solaris2.8/3.3.2/specs
Configured with: /db_backups/gcc/srcdir/gcc-3.3.2/configure 
--prefix=/usr/local/
bin/GNU --disable-nls --enable-threads=posix --enable-languages=c,c++ 
--with-sys
tem-zlib
Thread model: posix
gcc version 3.3.2

An ldd on the executable repors that it needs verion 5 of libstdc++.so.

ldd ./test
         libstdc++.so.5 =>               
/usr/local/bin/GNU/lib/libstdc++.so.5
         libm.so.1 =>                    /usr/lib/libm.so.1
         libgcc_s.so.1 =>                
/usr/local/bin/GNU/lib/libgcc_s.so.1
         libc.so.1 =>                    /usr/lib/libc.so.1
         libdl.so.1 =>                   /usr/lib/libdl.so.1
         /usr/platform/SUNW,Ultra-Enterprise/lib/libc_psr.so.1


Why is g++ referencing a specific version of a library instead of a generic 
name? I would have hope do seen libstdc++.so as the requirement.

This way if there was a bug in libstdc++.so.5, version libstdc++.so.6 can be 
installed, re-named to libstdc++.so and this would not require me to
re-build my executables.

>Can you tell g++ to use libstdc++.so instead of libstdc++.so.5
>
>Thanks in advance to all who answer

_________________________________________________________________
Is your PC infected? Get a FREE online computer virus scan from McAfee® 
Security. http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963

Re: shared libraries version

[llewelly]

"BeefStu BeefStu" <beefstu350@hotmail.com> writes:

> I have sample c++ program, which I am compiling (see steps below)
> onSolaris 2.8, which uses the following version of g++.
> 
> /usr/local/bin/GNU/bin/g++ -c ./test.cpp -o test.o
> /usr/local/bin/GNU/bin/g++ -g test.o -o test
> 
> 
> /usr/local/bin/GNU/bin/g++ -v
> Reading specs from
> /usr/local/bin/GNU/lib/gcc-lib/sparc-sun-solaris2.8/3.3.2/specs
> Configured with: /db_backups/gcc/srcdir/gcc-3.3.2/configure
> --prefix=/usr/local/
> bin/GNU --disable-nls --enable-threads=posix --enable-languages=c,c++
> --with-sys
> tem-zlib
> Thread model: posix
> gcc version 3.3.2
> 
> An ldd on the executable repors that it needs verion 5 of libstdc++.so.
> 
> ldd ./test
>          libstdc++.so.5 =>
> /usr/local/bin/GNU/lib/libstdc++.so.5
>          libm.so.1 =>                    /usr/lib/libm.so.1
>          libgcc_s.so.1 =>
> /usr/local/bin/GNU/lib/libgcc_s.so.1
>          libc.so.1 =>                    /usr/lib/libc.so.1
>          libdl.so.1 =>                   /usr/lib/libdl.so.1
>          /usr/platform/SUNW,Ultra-Enterprise/lib/libc_psr.so.1
> 
> 
> Why is g++ referencing a specific version of a library instead of a
> generic name? I would have hope do seen libstdc++.so as the
> requirement.
> 
> This way if there was a bug in libstdc++.so.5, version libstdc++.so.6
> can be installed, re-named to libstdc++.so and this would not require
> me to
> re-build my executables.

Unfortunately, libstdc++.so.5 (which is from gcc 3.3.x) and
    libstdc++.so.6 (which is from gcc 3.4.0) are not binary
    compatible.

The policy is change the version number on libstdc++.so every time a
    non-compatible change is made. Otherwise, the name isn't
    change. (For example, the libstdc++.so.5 shipped with gcc 3.3.3
    contains bugfixes not that shipped with 3.3.[012], yet they are
    all called libstdc++.so.5, becausee they are compatible.)

> 
> >Can you tell g++ to use libstdc++.so instead of libstdc++.so.5

No. If you could, every dynamicly linked program complied with
    libstdc++.so.5 would break if you then installed libstdc++.so.6,
    and the linker found libstdc++.so.6 instead.