Orlando Lewis wrote:
> Where can I find the following dependencies and/or what packages do they
> come with? I am using RH 6.1
>
> libstdc++_libc6.1-2.so.0
> libcrypto.so.0
>
> TIA
That's a good question as far I'm concerned, because I'm also getting
problems due to these as well as others, like libc.so.6. I have a symbolic
link libc.so.6 to some libc.so.2.0.7 file, or something like that, but
either this file isn't the correct version, although it looks like it
should be, because the libc.so.6 messages always say either "(GLIBC_2.0)"
or "(GLIBC_2.1)", and 2.0.7 is greater than 2.0.
However, I read something yesterday saying that libc* packages should be
removed, only leaving glibc* packages, but the documentation I've found on
this, so far, doesn't cover this much more than this, and I'm a little
concerned about removing the libc.5.4.* package until more thorough
documentation is found, or someone can answer the question based on real
experience.
I'm also getting problems with libm, libl, and others, as well as
libstdc++-libc6* and libcrypto*.
I've searched considerably for the answer, but haven't found anything more
than removing libc* and something very vague about symbolic links being
wrong and needing redefinition, or the files being copied to the correct
directory, and resinstalling some package(s). Haven't found any clear
documentation on this and if I do anything of what I've found so far, then
it'ld be by using very vague guidelines, so vague it leaves me wondering if
who ever wrote the documentation is sure of what he or she is saying, or
maybe it's just that they don't like to write, or can't translate
experience or knowledge into writing, or don't want to because they
wouldn't be getting paid.
What ever the reason, I haven't found any documentation leaving me feeling
reasonably confident; only leaving me feeling like I'm going by some
person's ideas, while it being really, only trial and error kind of
testing.
However, one piece of documentation I came across yesterday said that this
kind of problem is easier to avoid by avoiding RPMS and instead using
.tar.gz downloads, and then running configure, make and install. Actually,
this is the same piece of documentation first referred to, above. It said
that RPMs are supposedly, considerably unreliable in this way, whereas
downloading .tar.gz archives is considerably more reliable.
Of course, one could always try these guidelines, or installing RPMs using
the --nodeps (skip dependency checking) option, but I wouldn't do this
without first backing up the system. On the other hand, it may not be
necessary to backup the system, because if the --nodeps allows package
installation and then apps don't work, then the package(s) can probably be
removed without any problems. I don't know installation of RPMs well
enough to be able to say this for sure, though.
That's what I've found on this kind of topic, so far.
The first referenced piece of documentation is in the Software Building
HOWTO, which can be found through the LDP. I found it in the html HOWTOs,
there.
http://www.linuxdoc.org
mike
