g++ 3.1: libstdc++.so.3 problem

g++ 3.1: libstdc++.so.3 problem

[Oliver Kullmann]

Hi,

I have build gcc 3.1, and mostly it seems to be alright,
my programs compile without any messages and most of them
also run, except of one, where I get the error message:

error while loading shared libraries: libstdc++.so.3: cannot open shared 
object file: No such file or directory

Where should this libstdc++.so.3 be?! It's not in the
implementation lib-directory, which only contains

gcc-lib        libiberty.a   libstdc++.so        libsupc++.a
libgcc_s.so    libstdc++.a   libstdc++.so.4      libsupc++.la
libgcc_s.so.1  libstdc++.la  libstdc++.so.4.0.0

As I said, the compilation doesn't give any warnings, so it shouldn't
be a deprecated header. What is the problem here?!

Any help is greatly appreciated!

Oliver

Re: g++ 3.1: libstdc++.so.3 problem

[Oliver Kullmann]

On Wednesday 10 July 2002 13:48, you wrote:
> Oliver Kullmann wrote:
> >Hi,
> >
> >I have build gcc 3.1, and mostly it seems to be alright,
> >my programs compile without any messages and most of them
> >also run, except of one, where I get the error message:
> >
> >error while loading shared libraries: libstdc++.so.3: cannot open shared
> >object file: No such file or directory
> >
> >Where should this libstdc++.so.3 be?! It's not in the
> >implementation lib-directory, which only contains
> >
> >gcc-lib        libiberty.a   libstdc++.so        libsupc++.a
> >libgcc_s.so    libstdc++.a   libstdc++.so.4      libsupc++.la
> >libgcc_s.so.1  libstdc++.la  libstdc++.so.4.0.0
> >
> >As I said, the compilation doesn't give any warnings, so it shouldn't
> >be a deprecated header. What is the problem here?!
> >
> >Any help is greatly appreciated!
> >
> >Oliver
>
> Login as root and make a soft link as follows:
>  $ ln  -s  libstdc++.so.4.0.0  libstdc++.so.3
> then refresh share library info using ldconfig:
> $ ldconfig
>   This maybe help you.
>
> Good Luck.

Thanks a lot! Unfortunately, I don't have root access to this
(remote) machine --- I 	have requested the changes, but according
to my experiences this may never happen.

Therefore I do static compilation, and give the link to the library:

/GCC/gcc31/bin/g++ -static -L/GCC/gcc31/lib/ program.cpp

where GCC/gcc31 is the installation directory.
Since I can not change the dynamic linking, it seems necessary
to avoid any dynamic linking. How can I force g++ to really do
no dynamic linking?!

-- 
Dr. Oliver Kullmann
Computer Science Department
University of Wales Swansea
Faraday Building, Singleton Park
Swansea SA2 8PP, UK
http://cs-svr1.swan.ac.uk/~csoliver/

Re: g++ 3.1: libstdc++.so.3 problem

[Gokhan Kisacikoglu]

follow these steps;

1. create a library directory in your home account
2. go there 
3. create a symbolic link to libstdc++.so.4.0.0
4. alter your library load path so that it also looks in your library
directory

Now you can have your own dynamic libraries loaded.



in tcsh shell:

1. mkdir $HOME/lib
2. cd $HOME/lib
3. ln -s /usr/lib/libstdc++.so.4.0.0 libstdc++.so.3
4. setenv LD_LIBRARY_PATH ${LD_LIBRARY_PATH}:$HOME/lib




Oliver Kullmann wrote:
> 
> On Wednesday 10 July 2002 13:48, you wrote:
> > Oliver Kullmann wrote:
> > >Hi,
> > >
> > >I have build gcc 3.1, and mostly it seems to be alright,
> > >my programs compile without any messages and most of them
> > >also run, except of one, where I get the error message:
> > >
> > >error while loading shared libraries: libstdc++.so.3: cannot open shared
> > >object file: No such file or directory
> > >
> > >Where should this libstdc++.so.3 be?! It's not in the
> > >implementation lib-directory, which only contains
> > >
> > >gcc-lib        libiberty.a   libstdc++.so        libsupc++.a
> > >libgcc_s.so    libstdc++.a   libstdc++.so.4      libsupc++.la
> > >libgcc_s.so.1  libstdc++.la  libstdc++.so.4.0.0
> > >
> > >As I said, the compilation doesn't give any warnings, so it shouldn't
> > >be a deprecated header. What is the problem here?!
> > >
> > >Any help is greatly appreciated!
> > >
> > >Oliver
> >
> > Login as root and make a soft link as follows:
> >  $ ln  -s  libstdc++.so.4.0.0  libstdc++.so.3
> > then refresh share library info using ldconfig:
> > $ ldconfig
> >   This maybe help you.
> >
> > Good Luck.
> 
> Thanks a lot! Unfortunately, I don't have root access to this
> (remote) machine --- I  have requested the changes, but according
> to my experiences this may never happen.
> 
> Therefore I do static compilation, and give the link to the library:
> 
> /GCC/gcc31/bin/g++ -static -L/GCC/gcc31/lib/ program.cpp
> 
> where GCC/gcc31 is the installation directory.
> Since I can not change the dynamic linking, it seems necessary
> to avoid any dynamic linking. How can I force g++ to really do
> no dynamic linking?!
> 
> --
> Dr. Oliver Kullmann
> Computer Science Department
> University of Wales Swansea
> Faraday Building, Singleton Park
> Swansea SA2 8PP, UK
> http://cs-svr1.swan.ac.uk/~csoliver/

-- 
Gökhan Kisacikoglu    			     Centropolis Effects, LLC
Senior Technical Director		     10950 W Washington Blvd
kisa@centropolisfx.com   310.204.7300 x263   Culver City, CA, 90232
Key: Gö(GIrl)-khan Kis(cirCUS)-a-(Art)-cik(loGIC)-og(thOUGH)-lu(fLU)

Re: g++ 3.1: libstdc++.so.3 problem

[Andris Pavenis]

On Tue, 9 Jul 2002, Oliver Kullmann wrote:

> Hi,
>
> I have build gcc 3.1, and mostly it seems to be alright,
> my programs compile without any messages and most of them
> also run, except of one, where I get the error message:
>
> error while loading shared libraries: libstdc++.so.3: cannot open shared
> object file: No such file or directory
>
> Where should this libstdc++.so.3 be?! It's not in the
> implementation lib-directory, which only contains
>
> gcc-lib        libiberty.a   libstdc++.so        libsupc++.a
> libgcc_s.so    libstdc++.a   libstdc++.so.4      libsupc++.la
> libgcc_s.so.1  libstdc++.la  libstdc++.so.4.0.0
>
> As I said, the compilation doesn't give any warnings, so it shouldn't
> be a deprecated header. What is the problem here?!
>

Perhaps You have some shared library linked with libstdc++.so.3 (compiled
with gcc-3.0.X). Try using ldd -v ... for executable which requires
libstdc++.so.3 and find which it is. After that rebuild related package
with gcc-3.1.

Andris

Re: g++ 3.1: libstdc++.so.3 problem

[Oliver Kullmann]

On Thursday 11 July 2002 07:57, you wrote:
> On Tue, 9 Jul 2002, Oliver Kullmann wrote:
> > Hi,
> >
> > I have build gcc 3.1, and mostly it seems to be alright,
> > my programs compile without any messages and most of them
> > also run, except of one, where I get the error message:
> >
> > error while loading shared libraries: libstdc++.so.3: cannot open shared
> > object file: No such file or directory
> >
> > Where should this libstdc++.so.3 be?! It's not in the
> > implementation lib-directory, which only contains
> >
> > gcc-lib        libiberty.a   libstdc++.so        libsupc++.a
> > libgcc_s.so    libstdc++.a   libstdc++.so.4      libsupc++.la
> > libgcc_s.so.1  libstdc++.la  libstdc++.so.4.0.0
> >
> > As I said, the compilation doesn't give any warnings, so it shouldn't
> > be a deprecated header. What is the problem here?!
>
> Perhaps You have some shared library linked with libstdc++.so.3 (compiled
> with gcc-3.0.X). Try using ldd -v ... for executable which requires
> libstdc++.so.3 and find which it is. After that rebuild related package
> with gcc-3.1.
>
> Andris

Might be. I managed to get the links right, but now when running the
program I get

Segmentation fault

(where the program should just output a message to cout).

Running ldd gives

> ldd -v OKgenerator
        libstdc++.so.4 => /csoliver/GCC/gcc31/lib/libstdc++.so.4 (0x40029000)
        libm.so.6 => /lib/libm.so.6 (0x400d9000)
        libgcc_s.so.1 => /csoliver/GCC/gcc31/lib/libgcc_s.so.1 (0x400fb000)
        libc.so.6 => /lib/libc.so.6 (0x40104000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

        Version information:
        ./OKgenerator:
                libgcc_s.so.1 (GCC_3.0) => 
/csoliver/GCC/gcc31/lib/libgcc_s.so.1
                libc.so.6 (GLIBC_2.0) => /lib/libc.so.6
        /csoliver/GCC/gcc31/lib/libstdc++.so.4:
                libgcc_s.so.1 (GCC_3.0) => 
/csoliver/GCC/gcc31/lib/libgcc_s.so.1
                libc.so.6 (GLIBC_2.2) => /lib/libc.so.6
                libc.so.6 (GLIBC_2.1.3) => /lib/libc.so.6
                libc.so.6 (GLIBC_2.1) => /lib/libc.so.6
                libc.so.6 (GLIBC_2.0) => /lib/libc.so.6
        /lib/libm.so.6:
                libc.so.6 (GLIBC_2.1.3) => /lib/libc.so.6
                libc.so.6 (GLIBC_2.0) => /lib/libc.so.6
        /csoliver/GCC/gcc31/lib/libgcc_s.so.1:
                libc.so.6 (GLIBC_2.1.3) => /lib/libc.so.6
                libc.so.6 (GLIBC_2.0) => /lib/libc.so.6
        /lib/libc.so.6:
                ld-linux.so.2 (GLIBC_2.1.1) => /lib/ld-linux.so.2
                ld-linux.so.2 (GLIBC_2.2.3) => /lib/ld-linux.so.2
                ld-linux.so.2 (GLIBC_2.1) => /lib/ld-linux.so.2
                ld-linux.so.2 (GLIBC_2.2) => /lib/ld-linux.so.2
                ld-linux.so.2 (GLIBC_2.0) => /lib/ld-linux.so.2


where

/csoliver/GCC/gcc31/

is the implementation directory. Now I don't know how to
interprete this?!

Previously, one gcc 2.95.3 has been installed in the machine.
So there shouldn't be anything else (except the new installation).

Perhaps the problems are caused by

lib/libc.so.6

or

lib/ld-linux.so.2

?!

Oliver