Re: Case history: Installing libstdc++ on i686-pc-linux-gnu (Red Hat)

Re: Case history: Installing libstdc++ on i686-pc-linux-gnu (Red Hat)

[Avi Green]

Benjamin Kosnik wrote:

> libstdc++-2.90.8 is libstdc++-v3: . . . libstdc++.so.3.0.0
> libstdc++-v2 is in the gcc releases. . . libstdc++.a.2.10.0

Thanks a lot, Ben.  I'm really trying.


> this list is for libstdc++-v3. The occasional confused question about v2
> is permitted, but not actively encouraged...

OK, now I know better.  (So IS there a list for v2?)

Anyway, I successfully built v3, including the gcc rebuild, but my
libraries are all messed up now.  Is there anyone who's willing to help
me?  I have a vanilla Red Hat 6.0 system, plus the gcc-2.95 devel RPMs,
plus v3.  A simple hello.cpp program generates the following on compile:

$ g++ -I/usr/libstdc++-2.90.8/include/g++-v3 -L/usr/libstdc++-2.90.8/lib
Hello.cpp
/tmp/cc2CbfSP.o: In function `main':
/tmp/cc2CbfSP.o(.text+0x26): undefined reference to `cout'
/tmp/cc2CbfSP.o(.text+0x2b): undefined reference to `basic_ostream<char,
char_traits<char> > & operator<<<char_traits<char> >(basic_ostream<char,
char_traits<char> > &, char const *)'
/tmp/cc2CbfSP.o(.text+0x36): undefined reference to `basic_ostream<char,
char_traits<char> >::operator<<(basic_ostream<char, char_traits<char> >
&(*)(basic_ostream<char, char_traits<char> > &))'
/tmp/cc2CbfSP.o: In function `Hello::~Hello(void)':
/tmp/cc2CbfSP.o(.text+0xbf): undefined reference to `cout'
/tmp/cc2CbfSP.o(.text+0xc4): undefined reference to `basic_ostream<char,
char_traits<char> > & operator<<<char_traits<char> >(basic_ostream<char,
char_traits<char> > &, char const *)'
/tmp/cc2CbfSP.o(.text+0xcf): undefined reference to `basic_ostream<char,
char_traits<char> >::operator<<(basic_ostream<char, char_traits<char> >
&(*)(basic_ostream<char, char_traits<char> > &))'
/tmp/cc2CbfSP.o: In function
`__static_initialization_and_destruction_0':
/tmp/cc2CbfSP.o(.text+0x116): undefined reference to
`ios_base::Init::Init(void)'
/tmp/cc2CbfSP.o(.text+0x12b): undefined reference to
`ios_base::Init::~Init(void)'
/tmp/cc2CbfSP.o: In function `basic_ostream<char, char_traits<char> > &
flush<char, char_traits<char> >(basic_ostream<char, char_traits<char> >
&)':
/tmp/cc2CbfSP.o(.basic_ostream<char, char_traits<char> > &
gnu.linkonce.t.flush<char, char_traits<char> >(basic_ostream<char,
char_traits<char> > &)+0xe): undefined reference to `basic_ostream<char,
char_traits<char> >::flush(void)'
/tmp/cc2CbfSP.o: In function `basic_ostream<char, char_traits<char> > &
endl<char, char_traits<char> >(basic_ostream<char, char_traits<char> >
&)':
/tmp/cc2CbfSP.o(.basic_ostream<char, char_traits<char> > &
gnu.linkonce.t.endl<char, char_traits<char> >(basic_ostream<char,
char_traits<char> > &)+0x18): undefined reference to `basic_ios<char,
char_traits<char> >::widen(char) const'
/tmp/cc2CbfSP.o(.basic_ostream<char, char_traits<char> > &
gnu.linkonce.t.endl<char, char_traits<char> >(basic_ostream<char,
char_traits<char> > &)+0x2a): undefined reference to
`basic_ostream<char, char_traits<char> >::put(char)'
/usr/libstdc++-2.90.8/lib/libstdc++.so: undefined reference to
`std::bad_alloc::~bad_alloc(void)'
/usr/libstdc++-2.90.8/lib/libstdc++.so: undefined reference to
`std::exception type_info function'
/usr/libstdc++-2.90.8/lib/libstdc++.so: undefined reference to
`std::bad_cast type_info node'
/usr/libstdc++-2.90.8/lib/libstdc++.so: undefined reference to
`std::bad_cast virtual table'
/usr/libstdc++-2.90.8/lib/libstdc++.so: undefined reference to
`std::bad_alloc virtual table'
/usr/libstdc++-2.90.8/lib/libstdc++.so: undefined reference to
`std::exception type_info node'
/usr/libstdc++-2.90.8/lib/libstdc++.so: undefined reference to
`std::bad_cast type_info function'
/usr/libstdc++-2.90.8/lib/libstdc++.so: undefined reference to
`std::terminate(void)'
/usr/libstdc++-2.90.8/lib/libstdc++.so: undefined reference to
`std::uncaught_exception(void)'
/usr/libstdc++-2.90.8/lib/libstdc++.so: undefined reference to
`std::exception virtual table'
collect2: ld returned 1 exit status



> > > So it seems that libstdc++ really CAN'T be built without the gcc
> > > source, unless the configure script is hacked or something, which
> > > seems overwhelming.
> 
> This part of the install documentation is now removed. Sorry for the
> confusion.
> 
> Please hang with us on the config/build/install docs. This part of
> libstdc++-v3 has undergone a lot of change in the last two months, and
> the documentation is still reeling from the changes. We're working to
> make the install process less painful--thanks to everybody who sent in
> feedback.

And your hard work is greatly appreciated.  I can't *imagine* installing
without your docs!  I've read them and reread them numerous times to get
things straight.  (Let me know if you want specific comments.)

Anyway, thanks for your response.

--Avi

p.s.  After I installed v3, I found that
/usr/lib/libstdc++-libc6.1-1.so.2
      had been removed.  I couldn't find any reference to that file in
the
      v3 source tree, but it could have been wiped by one of the 2.95.2
      RPMs.  Unfortunately it's needed for groff, which is used by
man(1).
      Anyway, any help is appreciated; if the problem was caused by some
      other install, I apologize in advance for bothering you.

$ man g++
/usr/bin/groff: error in loading shared libraries:
libstdc++-libc6.1-1.so.2: cannot open shared object file: No such file
or directory
/usr/bin/gtbl: error in loading shared libraries:
libstdc++-libc6.1-1.so.2: cannot open shared object file: No such file
or directory

$ ldd /usr/bin/groff
	libstdc++-libc6.1-1.so.2 => not found
	libm.so.6 => /lib/libm.so.6 (0x40018000)
	libc.so.6 => /lib/libc.so.6 (0x40034000)
	/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)




=========  Avi Green :) (: www.sputnik7.com  =========
=    Junior Unix S/A       Novice System Specialist  =
========  avi at sputnik7.com   212 217-1147  ========

Re: Case history: Installing libstdc++ on i686-pc-linux-gnu (RedHat)

[llewelly]

On Mon, 27 Mar 2000, Avi Green wrote:

[snip]
> plus v3.  A simple hello.cpp program generates the following on compile:
> 
> $ g++ -I/usr/libstdc++-2.90.8/include/g++-v3 -L/usr/libstdc++-2.90.8/lib

I believe you need to add '-fhonor-std' to your command line.

By default, libstdc++-v3 builds with namespace std enabled; that is,
  -fhonor-std .

However, for backwards compatiblity reasons, g++ treats namespace std as
  the global namespace by default.

So if you use 'std::cout' in your code, g++ will generate a reference to
  'cout' ... but libstdc++-v3 contains 'std::cout' , *not* 'cout' . 

> Hello.cpp
> /tmp/cc2CbfSP.o: In function `main':
> /tmp/cc2CbfSP.o(.text+0x26): undefined reference to `cout'

[big long fat snip, including error message and a second question I
  cannot answer.]

Re: Case history: Installing libstdc++ on i686-pc-linux-gnu (Red Hat)

[Alexandre Oliva]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 820 bytes --]

On Mar 27, 2000, Avi Green <avi-nospam@sputnik7.com> wrote:

> p.s.  After I installed v3, I found that
> /usr/lib/libstdc++-libc6.1-1.so.2 had been removed.  I couldn't find
> any reference to that file in the v3 source tree, but it could have
> been wiped by one of the 2.95.2 RPMs.

You should certainly arrange for this file not to be removed, even if
you upgrade libstdc++.  Did you upgrade libstdc++ using RPM?  There
must be a way to arrange for it to upgrade a package without removing
the previous version's libraries.

-- 
Alexandre Oliva    Enjoy Guaraná, see http://www.ic.unicamp.br/~oliva/
Cygnus Solutions, a Red Hat company        aoliva@{redhat, cygnus}.com
Free Software Developer and Evangelist    CS PhD student at IC-Unicamp
oliva@{lsd.ic.unicamp.br, gnu.org}   Write to mailing lists, not to me

Re: Case history: Installing libstdc++ on i686-pc-linux-gnu (Red Hat)

[Avi Green]

Alexandre Oliva wrote:

> > p.s.  After I installed v3, I found that
> > /usr/lib/libstdc++-libc6.1-1.so.2 had been removed.  I couldn't find
> > any reference to that file in the v3 source tree, but it could have
> > been wiped by one of the 2.95.2 RPMs.
> 
> You should certainly arrange for this file not to be removed, even if
> you upgrade libstdc++.  Did you upgrade libstdc++ using RPM?  There
> must be a way to arrange for it to upgrade a package without removing
> the previous version's libraries.

After two days of blindly scavenging all of my packages and logs,
I have finally realized (at 1 AM) that I was looking for the wrong
file all along: /usr/lib/libstdc++-libc6.1-1.so.2 is a symbolic link
to libstdc++-2-libc6.1-1-2.9.0.so on my system, and it's actually
the latter file which is gone.  Apparently it was removed by the
postinstall script from gcc-c++-2.95.2-3.i386.rpm as part of its
half-successful attempt to remove egcs-c++ from my system.  It also
upgraded my libstdc++-2-libc6.1-1-2.*.*.a and libstdc++-libc6.1-*.a.*.

So:  What should I do?  Should I look for an old copy of the
libstdc++-libc6.1-1.so.2 file on the 'net and just and paste it back
into /usr/lib?  A good deal of the commands on my system require it.
One idea: I observe that the gcc-c++ RPM info says that it "does
include the static standard C++ library and C++ header files; the
library for dynamically linking programs is available separately."
Perhaps that would solve the problem?  Or is this something I can
solve by pointing the libstdc++-libc6.1-1.so.2 symlink somewhere
else or by setting LD_LIBRARY_PATH?

Any help would be appreciated.

Thanks again,
Avi

p.s.  I couldn't find any mention of this in either the gcc docs or the
      libstdc++ docs.  One or two messages in the gcc-help list archive
      seemed vaguely related, but no dice.

p.p.s. For those interested, I have reconstructed the steps I took
      installing gcc and libstdc++ over the last week.  You won't need
      it to help me, but since I spent a few hours trying to reconstruct
      this sequence before I knew the problem lay with my installation
      of the gcc-c++ RPM, here it is:

0. Tried (& failed) to make gcc & g++ from tarballs.  Gave up.
1. Installed libstdc++-devel-2.95.2-3.i386.rpm
   Note: Querying the package reveals that it OBSOLETES
   gcc-libstdc++-devel
2. Tried to install gcc-2.95.2-3.i386.rpm but was told I needed an
   up-to-date version of binutils (and cpp?)
3. Tried to install cpp-2.95.2-3.i386.rpm but was told I needed an
   up-to-date version of binutils
4. Installed binutils-2.9.4.0.6-1.i386.rpm
5. Installed cpp-2.95.2-3.i386.rpm
6. Tried to install gcc-2.95.2-3.i386.rpm but was told that
   egcs = 1.1.2 is needed by egcs-c++-1.1.2-12
7. Installed gcc-2.95.2-3.i386.rpm using rpm -U --nodeps
   Note: Querying the package reveals that it OBSOLETES egcs.
   This removed various files in /usr/lib/gcc-lib/i386-redhat-linux/
   egcs-2.91.66.  It also removed the egcs (1.1.2) package.
7. Installed gcc-c++-2.95.2-3.i386.rpm
   Note: Querying the package reveals that it OBSOLETES egcs-c++.
   Interestingly, my installation log for this RPM reveals that
   libstdc++-libc6.1-1.so.2, the missing file, is a dependency:
     D: dependencies: looking for libstdc++-libc6.1-1.so.2
     ...
     D: removing provides index for libstdc++-libc6.1-1.so.2
     D: removing provides index for libstdc++-libc6.1-1.so.2
        (GCC.INTERNAL)
   Apparently this removed the egcs-c++ package, which contained
   libstdc++-2-libc6.1-1-2.9.0.so
8. Made and installed libstdc++-2.90.8 from tarball.
   Played with the links.
9. Discovered that the man(1) command no longer worked because
   libstdc++-2-libc6.1-1-2.9.0.so (a.k.a. libstdc++-libc6.1-1.so.2)
   was no longer on the system.
   

=========  Avi Green :) (: www.sputnik7.com  =========
========     Unix S/A & System Specialist     ========
========  avi at sputnik7.com   212 217-1147  ========

Re: Case history: Installing libstdc++ on i686-pc-linux-gnu (Red Hat)

[Avi Green]

I wrote:

> So:  What should I do?  Should I look for an old copy of the
> libstdc++-libc6.1-1.so.2 file on the 'net and just and paste it back
> into /usr/lib?  A good deal of the commands on my system require it.
> One idea: I observe that the gcc-c++ RPM info says that it "does
> include the static standard C++ library and C++ header files; the
> library for dynamically linking programs is available separately."
> Perhaps that would solve the problem?  Or is this something I can
> solve by pointing the libstdc++-libc6.1-1.so.2 symlink somewhere
> else or by setting LD_LIBRARY_PATH?

I found a non-RPM (finally!) copy of libstdc++-libc6.1-1.so.2 in the
Slackware distribution.  I copied it into /usr/lib, and my commands
seem to work fine now.  Using ldd(1), I determined that none of the
other missing library files are needed by my system except for
lib[cm].so.5 and libstdc++.so.27, and although the links with those
names were gone, fortunately the underlying files weren't, and I was
able to resolve all of the library dependency problems by putting
the files and links back into /usr/lib.  Hopefully this won't break
anything in the new libraries.  (Right?)

Thanks to everyone for listening.

--Avi


=========  Avi Green :) (: www.sputnik7.com  =========
========     Unix S/A & System Specialist     ========
========  avi at sputnik7.com   212 217-1147  ========

Re: Case history: Installing libstdc++ on i686-pc-linux-gnu (Red Hat)

[Avi Green]

I wrote:

> So:  What should I do?  Should I look for an old copy of the
> libstdc++-libc6.1-1.so.2 file on the 'net and just and paste it back
> into /usr/lib?  A good deal of the commands on my system require it.
> One idea: I observe that the gcc-c++ RPM info says that it "does
> include the static standard C++ library and C++ header files; the
> library for dynamically linking programs is available separately."
> Perhaps that would solve the problem?  Or is this something I can
> solve by pointing the libstdc++-libc6.1-1.so.2 symlink somewhere
> else or by setting LD_LIBRARY_PATH?

I found a non-RPM (finally!) copy of libstdc++-libc6.1-1.so.2 in the
Slackware distribution.  I copied it into /usr/lib, and my commands
seem to work fine now.  Using ldd(1), I determined that none of the
other missing library files are needed by my system except for
lib[cm].so.5 and libstdc++.so.27, and although the links with those
names were gone, fortunately the underlying files weren't, and I was
able to resolve all of the library dependency problems by putting
the files and links back into /usr/lib.  Hopefully this won't break
anything in the new libraries.  (Right?)

Thanks to everyone for listening.

--Avi


=========  Avi Green :) (: www.sputnik7.com  =========
========     Unix S/A & System Specialist     ========
========  avi at sputnik7.com   212 217-1147  ========

Re: Case history: Installing libstdc++ on i686-pc-linux-gnu (RedHat)

[llewelly]

On Mon, 27 Mar 2000, Avi Green wrote:

[snip]
> plus v3.  A simple hello.cpp program generates the following on compile:
> 
> $ g++ -I/usr/libstdc++-2.90.8/include/g++-v3 -L/usr/libstdc++-2.90.8/lib

I believe you need to add '-fhonor-std' to your command line.

By default, libstdc++-v3 builds with namespace std enabled; that is,
  -fhonor-std .

However, for backwards compatiblity reasons, g++ treats namespace std as
  the global namespace by default.

So if you use 'std::cout' in your code, g++ will generate a reference to
  'cout' ... but libstdc++-v3 contains 'std::cout' , *not* 'cout' . 

> Hello.cpp
> /tmp/cc2CbfSP.o: In function `main':
> /tmp/cc2CbfSP.o(.text+0x26): undefined reference to `cout'

[big long fat snip, including error message and a second question I
  cannot answer.]

Re: Case history: Installing libstdc++ on i686-pc-linux-gnu (Red Hat)

[Avi Green]

Benjamin Kosnik wrote:

> libstdc++-2.90.8 is libstdc++-v3: . . . libstdc++.so.3.0.0
> libstdc++-v2 is in the gcc releases. . . libstdc++.a.2.10.0

Thanks a lot, Ben.  I'm really trying.


> this list is for libstdc++-v3. The occasional confused question about v2
> is permitted, but not actively encouraged...

OK, now I know better.  (So IS there a list for v2?)

Anyway, I successfully built v3, including the gcc rebuild, but my
libraries are all messed up now.  Is there anyone who's willing to help
me?  I have a vanilla Red Hat 6.0 system, plus the gcc-2.95 devel RPMs,
plus v3.  A simple hello.cpp program generates the following on compile:

$ g++ -I/usr/libstdc++-2.90.8/include/g++-v3 -L/usr/libstdc++-2.90.8/lib
Hello.cpp
/tmp/cc2CbfSP.o: In function `main':
/tmp/cc2CbfSP.o(.text+0x26): undefined reference to `cout'
/tmp/cc2CbfSP.o(.text+0x2b): undefined reference to `basic_ostream<char,
char_traits<char> > & operator<<<char_traits<char> >(basic_ostream<char,
char_traits<char> > &, char const *)'
/tmp/cc2CbfSP.o(.text+0x36): undefined reference to `basic_ostream<char,
char_traits<char> >::operator<<(basic_ostream<char, char_traits<char> >
&(*)(basic_ostream<char, char_traits<char> > &))'
/tmp/cc2CbfSP.o: In function `Hello::~Hello(void)':
/tmp/cc2CbfSP.o(.text+0xbf): undefined reference to `cout'
/tmp/cc2CbfSP.o(.text+0xc4): undefined reference to `basic_ostream<char,
char_traits<char> > & operator<<<char_traits<char> >(basic_ostream<char,
char_traits<char> > &, char const *)'
/tmp/cc2CbfSP.o(.text+0xcf): undefined reference to `basic_ostream<char,
char_traits<char> >::operator<<(basic_ostream<char, char_traits<char> >
&(*)(basic_ostream<char, char_traits<char> > &))'
/tmp/cc2CbfSP.o: In function
`__static_initialization_and_destruction_0':
/tmp/cc2CbfSP.o(.text+0x116): undefined reference to
`ios_base::Init::Init(void)'
/tmp/cc2CbfSP.o(.text+0x12b): undefined reference to
`ios_base::Init::~Init(void)'
/tmp/cc2CbfSP.o: In function `basic_ostream<char, char_traits<char> > &
flush<char, char_traits<char> >(basic_ostream<char, char_traits<char> >
&)':
/tmp/cc2CbfSP.o(.basic_ostream<char, char_traits<char> > &
gnu.linkonce.t.flush<char, char_traits<char> >(basic_ostream<char,
char_traits<char> > &)+0xe): undefined reference to `basic_ostream<char,
char_traits<char> >::flush(void)'
/tmp/cc2CbfSP.o: In function `basic_ostream<char, char_traits<char> > &
endl<char, char_traits<char> >(basic_ostream<char, char_traits<char> >
&)':
/tmp/cc2CbfSP.o(.basic_ostream<char, char_traits<char> > &
gnu.linkonce.t.endl<char, char_traits<char> >(basic_ostream<char,
char_traits<char> > &)+0x18): undefined reference to `basic_ios<char,
char_traits<char> >::widen(char) const'
/tmp/cc2CbfSP.o(.basic_ostream<char, char_traits<char> > &
gnu.linkonce.t.endl<char, char_traits<char> >(basic_ostream<char,
char_traits<char> > &)+0x2a): undefined reference to
`basic_ostream<char, char_traits<char> >::put(char)'
/usr/libstdc++-2.90.8/lib/libstdc++.so: undefined reference to
`std::bad_alloc::~bad_alloc(void)'
/usr/libstdc++-2.90.8/lib/libstdc++.so: undefined reference to
`std::exception type_info function'
/usr/libstdc++-2.90.8/lib/libstdc++.so: undefined reference to
`std::bad_cast type_info node'
/usr/libstdc++-2.90.8/lib/libstdc++.so: undefined reference to
`std::bad_cast virtual table'
/usr/libstdc++-2.90.8/lib/libstdc++.so: undefined reference to
`std::bad_alloc virtual table'
/usr/libstdc++-2.90.8/lib/libstdc++.so: undefined reference to
`std::exception type_info node'
/usr/libstdc++-2.90.8/lib/libstdc++.so: undefined reference to
`std::bad_cast type_info function'
/usr/libstdc++-2.90.8/lib/libstdc++.so: undefined reference to
`std::terminate(void)'
/usr/libstdc++-2.90.8/lib/libstdc++.so: undefined reference to
`std::uncaught_exception(void)'
/usr/libstdc++-2.90.8/lib/libstdc++.so: undefined reference to
`std::exception virtual table'
collect2: ld returned 1 exit status



> > > So it seems that libstdc++ really CAN'T be built without the gcc
> > > source, unless the configure script is hacked or something, which
> > > seems overwhelming.
> 
> This part of the install documentation is now removed. Sorry for the
> confusion.
> 
> Please hang with us on the config/build/install docs. This part of
> libstdc++-v3 has undergone a lot of change in the last two months, and
> the documentation is still reeling from the changes. We're working to
> make the install process less painful--thanks to everybody who sent in
> feedback.

And your hard work is greatly appreciated.  I can't *imagine* installing
without your docs!  I've read them and reread them numerous times to get
things straight.  (Let me know if you want specific comments.)

Anyway, thanks for your response.

--Avi

p.s.  After I installed v3, I found that
/usr/lib/libstdc++-libc6.1-1.so.2
      had been removed.  I couldn't find any reference to that file in
the
      v3 source tree, but it could have been wiped by one of the 2.95.2
      RPMs.  Unfortunately it's needed for groff, which is used by
man(1).
      Anyway, any help is appreciated; if the problem was caused by some
      other install, I apologize in advance for bothering you.

$ man g++
/usr/bin/groff: error in loading shared libraries:
libstdc++-libc6.1-1.so.2: cannot open shared object file: No such file
or directory
/usr/bin/gtbl: error in loading shared libraries:
libstdc++-libc6.1-1.so.2: cannot open shared object file: No such file
or directory

$ ldd /usr/bin/groff
	libstdc++-libc6.1-1.so.2 => not found
	libm.so.6 => /lib/libm.so.6 (0x40018000)
	libc.so.6 => /lib/libc.so.6 (0x40034000)
	/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)




=========  Avi Green :) (: www.sputnik7.com  =========
=    Junior Unix S/A       Novice System Specialist  =
========  avi at sputnik7.com   212 217-1147  ========

Re: Case history: Installing libstdc++ on i686-pc-linux-gnu (Red Hat)

[Alexandre Oliva]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 820 bytes --]

On Mar 27, 2000, Avi Green <avi-nospam@sputnik7.com> wrote:

> p.s.  After I installed v3, I found that
> /usr/lib/libstdc++-libc6.1-1.so.2 had been removed.  I couldn't find
> any reference to that file in the v3 source tree, but it could have
> been wiped by one of the 2.95.2 RPMs.

You should certainly arrange for this file not to be removed, even if
you upgrade libstdc++.  Did you upgrade libstdc++ using RPM?  There
must be a way to arrange for it to upgrade a package without removing
the previous version's libraries.

-- 
Alexandre Oliva    Enjoy Guaraná, see http://www.ic.unicamp.br/~oliva/
Cygnus Solutions, a Red Hat company        aoliva@{redhat, cygnus}.com
Free Software Developer and Evangelist    CS PhD student at IC-Unicamp
oliva@{lsd.ic.unicamp.br, gnu.org}   Write to mailing lists, not to me

Re: Case history: Installing libstdc++ on i686-pc-linux-gnu (Red Hat)

[Avi Green]

Alexandre Oliva wrote:

> > p.s.  After I installed v3, I found that
> > /usr/lib/libstdc++-libc6.1-1.so.2 had been removed.  I couldn't find
> > any reference to that file in the v3 source tree, but it could have
> > been wiped by one of the 2.95.2 RPMs.
> 
> You should certainly arrange for this file not to be removed, even if
> you upgrade libstdc++.  Did you upgrade libstdc++ using RPM?  There
> must be a way to arrange for it to upgrade a package without removing
> the previous version's libraries.

After two days of blindly scavenging all of my packages and logs,
I have finally realized (at 1 AM) that I was looking for the wrong
file all along: /usr/lib/libstdc++-libc6.1-1.so.2 is a symbolic link
to libstdc++-2-libc6.1-1-2.9.0.so on my system, and it's actually
the latter file which is gone.  Apparently it was removed by the
postinstall script from gcc-c++-2.95.2-3.i386.rpm as part of its
half-successful attempt to remove egcs-c++ from my system.  It also
upgraded my libstdc++-2-libc6.1-1-2.*.*.a and libstdc++-libc6.1-*.a.*.

So:  What should I do?  Should I look for an old copy of the
libstdc++-libc6.1-1.so.2 file on the 'net and just and paste it back
into /usr/lib?  A good deal of the commands on my system require it.
One idea: I observe that the gcc-c++ RPM info says that it "does
include the static standard C++ library and C++ header files; the
library for dynamically linking programs is available separately."
Perhaps that would solve the problem?  Or is this something I can
solve by pointing the libstdc++-libc6.1-1.so.2 symlink somewhere
else or by setting LD_LIBRARY_PATH?

Any help would be appreciated.

Thanks again,
Avi

p.s.  I couldn't find any mention of this in either the gcc docs or the
      libstdc++ docs.  One or two messages in the gcc-help list archive
      seemed vaguely related, but no dice.

p.p.s. For those interested, I have reconstructed the steps I took
      installing gcc and libstdc++ over the last week.  You won't need
      it to help me, but since I spent a few hours trying to reconstruct
      this sequence before I knew the problem lay with my installation
      of the gcc-c++ RPM, here it is:

0. Tried (& failed) to make gcc & g++ from tarballs.  Gave up.
1. Installed libstdc++-devel-2.95.2-3.i386.rpm
   Note: Querying the package reveals that it OBSOLETES
   gcc-libstdc++-devel
2. Tried to install gcc-2.95.2-3.i386.rpm but was told I needed an
   up-to-date version of binutils (and cpp?)
3. Tried to install cpp-2.95.2-3.i386.rpm but was told I needed an
   up-to-date version of binutils
4. Installed binutils-2.9.4.0.6-1.i386.rpm
5. Installed cpp-2.95.2-3.i386.rpm
6. Tried to install gcc-2.95.2-3.i386.rpm but was told that
   egcs = 1.1.2 is needed by egcs-c++-1.1.2-12
7. Installed gcc-2.95.2-3.i386.rpm using rpm -U --nodeps
   Note: Querying the package reveals that it OBSOLETES egcs.
   This removed various files in /usr/lib/gcc-lib/i386-redhat-linux/
   egcs-2.91.66.  It also removed the egcs (1.1.2) package.
7. Installed gcc-c++-2.95.2-3.i386.rpm
   Note: Querying the package reveals that it OBSOLETES egcs-c++.
   Interestingly, my installation log for this RPM reveals that
   libstdc++-libc6.1-1.so.2, the missing file, is a dependency:
     D: dependencies: looking for libstdc++-libc6.1-1.so.2
     ...
     D: removing provides index for libstdc++-libc6.1-1.so.2
     D: removing provides index for libstdc++-libc6.1-1.so.2
        (GCC.INTERNAL)
   Apparently this removed the egcs-c++ package, which contained
   libstdc++-2-libc6.1-1-2.9.0.so
8. Made and installed libstdc++-2.90.8 from tarball.
   Played with the links.
9. Discovered that the man(1) command no longer worked because
   libstdc++-2-libc6.1-1-2.9.0.so (a.k.a. libstdc++-libc6.1-1.so.2)
   was no longer on the system.
   

=========  Avi Green :) (: www.sputnik7.com  =========
========     Unix S/A & System Specialist     ========
========  avi at sputnik7.com   212 217-1147  ========