Crashdamage wrote:
> OK, this has me stumped and my system is partially hosed. On this box
> I'm still running a years-old and much-modified by now installation of
> Mandrake 10.1.
> I've broken this 10.1 install plenty of
> times over the years doing this kind of stuff but *never* had to
> reinstall, I've always figured out the fix - 'til now.
>
> I know I deserve what I got, but please - any ideas??

Overwrite everything in /etc/ /usr /bin /sbin /lib and maybe
/var from backup? Drastic, but would likely work.

Cheers!

jim b.

--
UNIX is not user-unfriendly; it merely
expects users to be computer-friendly.

On 06 Jan 2008 17:09:57 GMT, Crashdamage <03z1krd7@nospam.invalid> wrote:
> OK, this has me stumped and my system is partially hosed. On this box
> I'm still running a years-old and much-modified by now installation of
> Mandrake 10.1. I've been using Firefox 2.0.0.11 installed from the
> Mozilla.org package with no problems. I decided I'd try out Firefox 3
> beta2 and installed it just as I always do, in /usr/local.

> This time it complained of needing minor version upgrades so to satisfy
> things so I upgraded:

> pango-1.8xx > pango-1.10xx
> libpango1.0_0-1.8xx > libpango1.0_0-1.10xx
> libpango1.0_0-modules-1.8xx > libpango1.0_0-modules-1.10xx
> libfreetype6-2.1.9xx > libfreetype6-2.1.10xx
> libfreetype6-devel-2.1.9xx > libfreetype6-devel-2.1.10xx

> ...all minor version upgrades, and added: libcairo2-1.0.0-5.1.101xx
> which was not previoulsy installed to satisfy a dependency for one of
> the packages, libpangol1, I think.

> Anyway, I did it all manually with rpm, installing all packages at once
> and of course checking first with the '--test' option before actual
> installation. All seemed fine. BUT...when I tried to launch Firefox3 I
> got this:

> $ firefox
> /usr/local/firefox/firefox-bin: symbol lookup error:
> /usr/lib/libssl.so.0.9.7: undefined symbol: EVP_idea_cbc

Jim b. - thanks, but I think I'll hold off on trying that for a while.
This has to be something simple. I'm just no programmer or guru and
can't get my head around it yet.

A little more info, maybe it'll help:

First, checked to see if 'EVP_idea_cbc' is indeed defined in
'libssl.so.0.9.7':

$ nm -D /usr/lib/libssl.so.0.9.7 | grep EVP
(snip)
U EVP_idea_cbc

I take it 'U' means undefined. So there must be an undefined
'EVP_idea_cbc' floating around somewhere holding things up, but I can't
find it. I'm not even sure *exactly* what it is.

Next, checked to see if libssl.so.0.9.7 is linked to all it's required
libraries:

$ ldd /usr/lib/libssl.so.0.9.7
linux-gate.so.1 => (0xffffe000)
libcrypto.so.0.9.7 => /opt/win4linpro/lib/sys/libcrypto.so.0.9.7
(0xb7ebf000)
libdl.so.2 => /lib/libdl.so.2 (0xb7ebc000)
libc.so.6 => /lib/tls/libc.so.6 (0xb7d9d000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000)

Apparently it is.

HELP! I'm not this smart!

--
Registered Linux user #266531

Crashdamage <03z1krd7@nospam.invalid> writes:

> On 06 Jan 2008 17:09:57 GMT, Crashdamage <03z1krd7@nospam.invalid> wrote:
>> OK, this has me stumped and my system is partially hosed. On this box
>> I'm still running a years-old and much-modified by now installation of
>> Mandrake 10.1. I've been using Firefox 2.0.0.11 installed from the
>> Mozilla.org package with no problems. I decided I'd try out Firefox 3
>> beta2 and installed it just as I always do, in /usr/local.
>
>> This time it complained of needing minor version upgrades so to satisfy
>> things so I upgraded:
>
>> pango-1.8xx > pango-1.10xx
>> libpango1.0_0-1.8xx > libpango1.0_0-1.10xx
>> libpango1.0_0-modules-1.8xx > libpango1.0_0-modules-1.10xx
>> libfreetype6-2.1.9xx > libfreetype6-2.1.10xx
>> libfreetype6-devel-2.1.9xx > libfreetype6-devel-2.1.10xx
>
>> ...all minor version upgrades, and added: libcairo2-1.0.0-5.1.101xx
>> which was not previoulsy installed to satisfy a dependency for one of
>> the packages, libpangol1, I think.
>
>> Anyway, I did it all manually with rpm, installing all packages at once
>> and of course checking first with the '--test' option before actual
>> installation. All seemed fine. BUT...when I tried to launch Firefox3 I
>> got this:
>
>> $ firefox
>> /usr/local/firefox/firefox-bin: symbol lookup error:
>> /usr/lib/libssl.so.0.9.7: undefined symbol: EVP_idea_cbc
>
> Jim b. - thanks, but I think I'll hold off on trying that for a while.
> This has to be something simple. I'm just no programmer or guru and
> can't get my head around it yet.
>
> A little more info, maybe it'll help:
>
> First, checked to see if 'EVP_idea_cbc' is indeed defined in
> 'libssl.so.0.9.7':
>
> $ nm -D /usr/lib/libssl.so.0.9.7 | grep EVP
> (snip)
> U EVP_idea_cbc
>
> I take it 'U' means undefined. So there must be an undefined
> 'EVP_idea_cbc' floating around somewhere holding things up, but I can't
> find it. I'm not even sure *exactly* what it is.
>
> Next, checked to see if libssl.so.0.9.7 is linked to all it's required
> libraries:
>
> $ ldd /usr/lib/libssl.so.0.9.7
> linux-gate.so.1 => (0xffffe000)
> libcrypto.so.0.9.7 => /opt/win4linpro/lib/sys/libcrypto.so.0.9.7
> (0xb7ebf000)
> libdl.so.2 => /lib/libdl.so.2 (0xb7ebc000)
> libc.so.6 => /lib/tls/libc.so.6 (0xb7d9d000)
> /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000)
>
> Apparently it is.
>
> HELP! I'm not this smart!

Those EVP symbols get resolved by libcrypto.so.
Your libcrypto is coming from a "strange" place.
(See above.)

I have a 10.1 system:

> nm -D /usr/lib/libcrypto.so | grep EVP_idea
00086ba0 T EVP_idea_cbc
00086bc0 T EVP_idea_cfb
00086c00 T EVP_idea_ecb
00086be0 T EVP_idea_ofb

My 10.1 system is on it's last legs.
I can no longer apply any RPMs because I went too far installing
stuff that didn't belong.
What you are doing leads to ultimate breakdown of the system.
I know this from experience.
You really need to upgrade to something current.

On Sun, 06 Jan 2008 14:55:42 -0500, Crashdamage <03z1krd7@nospam.invalid> wrote:

>> /usr/lib/libssl.so.0.9.7: undefined symbol: EVP_idea_cbc

You might want to try the 2008 version, libopenssl0.9.8-0.9.8e-8.1mdv2008.0
nm -D on that version does not include EVP_idea_cbc.

Regards, Dave Hodgins

--
Change nomail.afraid.org to ody.ca to reply by email.
(nomail.afraid.org has been set up specifically for
use in usenet. Feel free to use it yourself.)

On Sun, 06 Jan 2008 20:40:31 GMT, Dan Espen
wrote:
> Crashdamage <03z1krd7@nospam.invalid> writes:

>> On 06 Jan 2008 17:09:57 GMT, Crashdamage <03z1krd7@nospam.invalid> wrote:
>>> OK, this has me stumped and my system is partially hosed. On this box
>>> I'm still running a years-old and much-modified by now installation of
>>> Mandrake 10.1. I've been using Firefox 2.0.0.11 installed from the
>>> Mozilla.org package with no problems. I decided I'd try out Firefox 3
>>> beta2 and installed it just as I always do, in /usr/local.
>>
>>> This time it complained of needing minor version upgrades so to satisfy
>>> things so I upgraded:
>>
>>> pango-1.8xx > pango-1.10xx
>>> libpango1.0_0-1.8xx > libpango1.0_0-1.10xx
>>> libpango1.0_0-modules-1.8xx > libpango1.0_0-modules-1.10xx
>>> libfreetype6-2.1.9xx > libfreetype6-2.1.10xx
>>> libfreetype6-devel-2.1.9xx > libfreetype6-devel-2.1.10xx
>>
>>> ...all minor version upgrades, and added: libcairo2-1.0.0-5.1.101xx
>>> which was not previoulsy installed to satisfy a dependency for one of
>>> the packages, libpangol1, I think.
>>
>>> Anyway, I did it all manually with rpm, installing all packages at once
>>> and of course checking first with the '--test' option before actual
>>> installation. All seemed fine. BUT...when I tried to launch Firefox3 I
>>> got this:
>>
>>> $ firefox
>>> /usr/local/firefox/firefox-bin: symbol lookup error:
>>> /usr/lib/libssl.so.0.9.7: undefined symbol: EVP_idea_cbc
>>
>> Jim b. - thanks, but I think I'll hold off on trying that for a while.
>> This has to be something simple. I'm just no programmer or guru and
>> can't get my head around it yet.
>>
>> A little more info, maybe it'll help:
>>
>> First, checked to see if 'EVP_idea_cbc' is indeed defined in
>> 'libssl.so.0.9.7':
>>
>> $ nm -D /usr/lib/libssl.so.0.9.7 | grep EVP
>> (snip)
>> U EVP_idea_cbc
>>
>> I take it 'U' means undefined. So there must be an undefined
>> 'EVP_idea_cbc' floating around somewhere holding things up, but I can't
>> find it. I'm not even sure *exactly* what it is.
>>
>> Next, checked to see if libssl.so.0.9.7 is linked to all it's required
>> libraries:
>>
>> $ ldd /usr/lib/libssl.so.0.9.7
>> linux-gate.so.1 => (0xffffe000)
>> libcrypto.so.0.9.7 => /opt/win4linpro/lib/sys/libcrypto.so.0.9.7
>> (0xb7ebf000)
>> libdl.so.2 => /lib/libdl.so.2 (0xb7ebc000)
>> libc.so.6 => /lib/tls/libc.so.6 (0xb7d9d000)
>> /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000)
>>
>> Apparently it is.
>>
>> HELP! I'm not this smart!

> Those EVP symbols get resolved by libcrypto.so.
> Your libcrypto is coming from a "strange" place.
> (See above.)

Well, I assume it's supposed to be that way there since Win4Lin Pro
(and most other apps) is working fine.
'/opt/win4linpro/lib/sys/libcrypto.so.0.9.7' is installed as part of the
Win4LinPro rpm and that has not changed, so I doubt that is a problem.

The package 'libopenssl0.9.7-0.9.7e-5.2.102mdk' actually supplies
/usr/lib/libcrypto.so.0.9.7. I still have that original Mandrake package
installed. The neither libcrypto.so.0.9.7 itself or the link to it
libcrypto.so has changed. They're exactly the same as my backups.

> I have a 10.1 system:

>> nm -D /usr/lib/libcrypto.so | grep EVP_idea
> 00086ba0 T EVP_idea_cbc
> 00086bc0 T EVP_idea_cfb
> 00086c00 T EVP_idea_ecb
> 00086be0 T EVP_idea_ofb

$ nm -D /usr/lib/libcrypto.so | grep EVP_idea
00088aa0 T EVP_idea_cbc
00090920 T EVP_idea_cfb
00088ac0 T EVP_idea_cfb64
(Where did *that* come from? This not a 64bit machine or install.
Could it be the problem? The error dosen't specify 'idea_cbc64')
00088b00 T EVP_idea_ecb
00088ae0 T EVP_idea_ofb

> My 10.1 system is on it's last legs.
> I can no longer apply any RPMs because I went too far installing
> stuff that didn't belong.
> What you are doing leads to ultimate breakdown of the system.
> I know this from experience.
> You really need to upgrade to something current.

Mine probably is too but I'd *really* like to get maybe another year out
of it, build a new box and reinstall then. I realize you can only do so
much mucking around with upgrading odd packages, but by carefully
following rpm rules, etc. I've managed to keep the stuff I need current
and up to now it's been rock-stable.

Anyway, OK, the link libcrypto.so takes care of resolving the EVP's.
But how do I fix this? There must be a way - it's not like everything
is trashed. Seems like it should be fairly simple and doable - if I
knew what to do.

--
Registered Linux user #266531

On Sun, 06 Jan 2008 17:24:08 -0500, Crashdamage <03z1krd7@nospam.invalid> wrote:

> Anyway, OK, the link libcrypto.so takes care of resolving the EVP's.
> But how do I fix this? There must be a way - it's not like everything
> is trashed. Seems like it should be fairly simple and doable - if I
> knew what to do.

Looks like the problem may be due to the order the directories are being
searched. Change /etc/ld.so.conf so that /lib is searched first, followed
by /usr/lib, followed by anything added by other applications. Then
run ldconfig, and then confirm with ldd that the correct version of libcrypt
is being selected.

Regards, Dave Hodgins

--
Change nomail.afraid.org to ody.ca to reply by email.
(nomail.afraid.org has been set up specifically for
use in usenet. Feel free to use it yourself.)

On Sun, 06 Jan 2008 17:57:57 -0500, David W. Hodgins
wrote:
> On Sun, 06 Jan 2008 17:24:08 -0500, Crashdamage <03z1krd7@nospam.invalid> wrote:

>> Anyway, OK, the link libcrypto.so takes care of resolving the EVP's.
>> But how do I fix this? There must be a way - it's not like everything
>> is trashed. Seems like it should be fairly simple and doable - if I
>> knew what to do.

> Looks like the problem may be due to the order the directories are being
> searched. Change /etc/ld.so.conf so that /lib is searched first, followed
> by /usr/lib, followed by anything added by other applications. Then
> run ldconfig, and then confirm with ldd that the correct version of libcrypt
> is being selected.

My existing ld.so.conf doesn't search /lib at at all, but it hasn't
changed since Feb 2007 either so I don't think that's it. Here it is:

include ld.so.conf.d/*.conf
/usr/X11R6/lib
/usr/lib/qt3/lib
/opt/win4linpro/lib/sys

Are you saying I should just add '/lib' to the top of the directory
list? Isn't that too general?

At present, running '# ldconfig' returns nothing. Honestly, I've never
run that command. What exactly does it do and what should it return?

The version of libcrypt installed never changed, and it's still the
original. I carefully rolled all packages I did change back and made
sure only one version (the previous one) was still installed. Still,
*something* is not quite as it was.

At least I'm learning some stuff...thanks!

--
Registered Linux user #266531

On Sun, 06 Jan 2008 15:41:34 -0500, David W. Hodgins
wrote:
> On Sun, 06 Jan 2008 14:55:42 -0500, Crashdamage <03z1krd7@nospam.invalid> wrote:

>>> /usr/lib/libssl.so.0.9.7: undefined symbol: EVP_idea_cbc

> You might want to try the 2008 version, libopenssl0.9.8-0.9.8e-8.1mdv2008.0
> nm -D on that version does not include EVP_idea_cbc.

Hmmm....I dunno about that one. There's a *lot* of dependencies on that
package. I've gotta think that trying to shoehorn in a version that
much newer would likely cause more trouble than I've got now.

Thing is, as far as I can tell I put everything back as it was. But
*something* is still changed. The question is what and how do I fix
that?

Thanks for the help. I appreciate it.

--
Registered Linux user #266531

Crashdamage <03z1krd7@nospam.invalid> writes:

> On Sun, 06 Jan 2008 17:57:57 -0500, David W. Hodgins
> wrote:
>> On Sun, 06 Jan 2008 17:24:08 -0500, Crashdamage <03z1krd7@nospam.invalid> wrote:
>
>>> Anyway, OK, the link libcrypto.so takes care of resolving the EVP's.
>>> But how do I fix this? There must be a way - it's not like everything
>>> is trashed. Seems like it should be fairly simple and doable - if I
>>> knew what to do.
>
>> Looks like the problem may be due to the order the directories are being
>> searched. Change /etc/ld.so.conf so that /lib is searched first, followed
>> by /usr/lib, followed by anything added by other applications. Then
>> run ldconfig, and then confirm with ldd that the correct version of libcrypt
>> is being selected.
>
> My existing ld.so.conf doesn't search /lib at at all, but it hasn't
> changed since Feb 2007 either so I don't think that's it. Here it is:
>
> include ld.so.conf.d/*.conf
> /usr/X11R6/lib
> /usr/lib/qt3/lib
> /opt/win4linpro/lib/sys
>
> Are you saying I should just add '/lib' to the top of the directory
> list? Isn't that too general?

You could, at least to see what happens.
You could also export LD_LIBRARY_PATH to see what that does.
But...

> At present, running '# ldconfig' returns nothing. Honestly, I've never
> run that command. What exactly does it do and what should it return?

Try "man ldconfig".
It's normally run when you install a package.
Try:

ldconfig -v

if you want feedback.

> The version of libcrypt installed never changed, and it's still the
> original. I carefully rolled all packages I did change back and made
> sure only one version (the previous one) was still installed. Still,
> *something* is not quite as it was.

Actually, normal shared library versioning should be protecting you.
Perhaps you should post the output of:

ls -l /usr/lib/libcrypt*
ls -l /opt/win4linpro/lib/sys/libcrypt*

The program in question should be going for a specific version
of libcrypt and there shouldn't be 2 libraries with the same version
but different content.

> At least I'm learning some stuff...thanks!

A reward in it's own right.

On Mon, 07 Jan 2008 06:26:51 -0500, Crashdamage <03z1krd7@nospam.invalid> wrote:

> Are you saying I should just add '/lib' to the top of the directory
> list? Isn't that too general?

Yes, that's what I'm saying. Applications that require there own version
of a system module/library, should use a script to set the LD_PRELOAD environment
variable, to override the default dynamic linking order.

> At present, running '# ldconfig' returns nothing. Honestly, I've never
> run that command. What exactly does it do and what should it return?

It determines which entry points are in which dynamically loaded module,
and updates /etc/ld.so.cache, which is used by ld.so, to determine which
libraries to load, for a given module.

> The version of libcrypt installed never changed, and it's still the
> original. I carefully rolled all packages I did change back and made
> sure only one version (the previous one) was still installed. Still,
> *something* is not quite as it was.

The version of libcrypt being used by win4linpro, is not compatible with
the normal system wide version. It should only be used by win4linpro,
using the LD_PRELOAD environment variable.

> At least I'm learning some stuff...thanks!

The good thing about learning the hard way, is that you never forget, those
lessons.

One thing I've found helpful, is to install and run prelink, and then look
at the log file, to see which applications have missing dependencies. Much
easier then waiting for each application to fail, and then trying to figure
out which dependency is missing.

Regards, Dave Hodgins

--
Change nomail.afraid.org to ody.ca to reply by email.
(nomail.afraid.org has been set up specifically for
use in usenet. Feel free to use it yourself.)

On Mon, 07 Jan 2008 15:15:16 GMT, Dan Espen
wrote:
> Crashdamage <03z1krd7@nospam.invalid> writes:

>> On Sun, 06 Jan 2008 17:57:57 -0500, David W. Hodgins
>> wrote:
>>> On Sun, 06 Jan 2008 17:24:08 -0500, Crashdamage <03z1krd7@nospam.invalid> wrote:
>>
>>>> Anyway, OK, the link libcrypto.so takes care of resolving the EVP's.
>>>> But how do I fix this? There must be a way - it's not like everything
>>>> is trashed. Seems like it should be fairly simple and doable - if I
>>>> knew what to do.
>>
>>> Looks like the problem may be due to the order the directories are being
>>> searched. Change /etc/ld.so.conf so that /lib is searched first, followed
>>> by /usr/lib, followed by anything added by other applications. Then
>>> run ldconfig, and then confirm with ldd that the correct version of libcrypt
>>> is being selected.
>>
>> My existing ld.so.conf doesn't search /lib at at all, but it hasn't
>> changed since Feb 2007 either so I don't think that's it. Here it is:
>>
>> include ld.so.conf.d/*.conf
>> /usr/X11R6/lib
>> /usr/lib/qt3/lib
>> /opt/win4linpro/lib/sys
>>
>> Are you saying I should just add '/lib' to the top of the directory
>> list? Isn't that too general?

> You could, at least to see what happens.
> You could also export LD_LIBRARY_PATH to see what that does.
> But...

>> At present, running '# ldconfig' returns nothing. Honestly, I've never
>> run that command. What exactly does it do and what should it return?

> Try "man ldconfig".
> It's normally run when you install a package.
> Try:

> ldconfig -v

> if you want feedback.

That gave *lots* of feedback...

>> The version of libcrypt installed never changed, and it's still the
>> original. I carefully rolled all packages I did change back and made
>> sure only one version (the previous one) was still installed. Still,
>> *something* is not quite as it was.

> Actually, normal shared library versioning should be protecting you.
> Perhaps you should post the output of:

> ls -l /usr/lib/libcrypt*

$ ls -l /usr/lib/libcrypt*
lrwxrwxrwx 1 root root 38 Jan 7 23:38 /usr/lib/libcrypto.so ->
.../../../../usr/lib/libcrypto.so.0.9.7*
-rwxr-xr-x 1 root root 1038480 Oct 10 2005
/usr/lib/libcrypto.so.0.9.7*
lrwxrwxrwx 1 root root 33 Jan 7 23:38 /usr/lib/libcrypt.so ->
.../../../../lib/libcrypt-2.3.3.so*

Some of the above are very recent because I've been replacing stuff from
backups tonight trying to make sure everything is rolled back to
*exactly* as it was before all this started.

> ls -l /opt/win4linpro/lib/sys/libcrypt*

$ ls -l /opt/win4linpro/lib/sys/libcrypt*
-r--r--r-- 1 root bin 1029704 Dec 4 13:25
/opt/win4linpro/lib/sys/libcrypto.so.0.9.7


> The program in question should be going for a specific version
> of libcrypt and there shouldn't be 2 libraries with the same version
> but different content.

>> At least I'm learning some stuff...thanks!

> A reward in it's own right.

Thanks for trying to help.
--
Registered Linux user #266531

Crashdamage <03z1krd7@nospam.invalid> writes:

> On Mon, 07 Jan 2008 15:15:16 GMT, Dan Espen
> wrote:
>> Crashdamage <03z1krd7@nospam.invalid> writes:
>
>>> On Sun, 06 Jan 2008 17:57:57 -0500, David W. Hodgins
>>> wrote:
>>>> On Sun, 06 Jan 2008 17:24:08 -0500, Crashdamage <03z1krd7@nospam.invalid> wrote:
>>>
>>>>> Anyway, OK, the link libcrypto.so takes care of resolving the EVP's.
>>>>> But how do I fix this? There must be a way - it's not like everything
>>>>> is trashed. Seems like it should be fairly simple and doable - if I
>>>>> knew what to do.
>>>
>>>> Looks like the problem may be due to the order the directories are being
>>>> searched. Change /etc/ld.so.conf so that /lib is searched first, followed
>>>> by /usr/lib, followed by anything added by other applications. Then
>>>> run ldconfig, and then confirm with ldd that the correct version of libcrypt
>>>> is being selected.
>>>
>>> My existing ld.so.conf doesn't search /lib at at all, but it hasn't
>>> changed since Feb 2007 either so I don't think that's it. Here it is:
>>>
>>> include ld.so.conf.d/*.conf
>>> /usr/X11R6/lib
>>> /usr/lib/qt3/lib
>>> /opt/win4linpro/lib/sys
>>>
>>> Are you saying I should just add '/lib' to the top of the directory
>>> list? Isn't that too general?
>
>> You could, at least to see what happens.
>> You could also export LD_LIBRARY_PATH to see what that does.
>> But...
>
>>> At present, running '# ldconfig' returns nothing. Honestly, I've never
>>> run that command. What exactly does it do and what should it return?
>
>> Try "man ldconfig".
>> It's normally run when you install a package.
>> Try:
>
>> ldconfig -v
>
>> if you want feedback.
>
> That gave *lots* of feedback...
>
>>> The version of libcrypt installed never changed, and it's still the
>>> original. I carefully rolled all packages I did change back and made
>>> sure only one version (the previous one) was still installed. Still,
>>> *something* is not quite as it was.
>
>> Actually, normal shared library versioning should be protecting you.
>> Perhaps you should post the output of:
>
>> ls -l /usr/lib/libcrypt*
>
> $ ls -l /usr/lib/libcrypt*
> lrwxrwxrwx 1 root root 38 Jan 7 23:38 /usr/lib/libcrypto.so ->
> ../../../../usr/lib/libcrypto.so.0.9.7*
> -rwxr-xr-x 1 root root 1038480 Oct 10 2005
> /usr/lib/libcrypto.so.0.9.7*
> lrwxrwxrwx 1 root root 33 Jan 7 23:38 /usr/lib/libcrypt.so ->
> ../../../../lib/libcrypt-2.3.3.so*
>
> Some of the above are very recent because I've been replacing stuff from
> backups tonight trying to make sure everything is rolled back to
> *exactly* as it was before all this started.
>
>> ls -l /opt/win4linpro/lib/sys/libcrypt*
>
> $ ls -l /opt/win4linpro/lib/sys/libcrypt*
> -r--r--r-- 1 root bin 1029704 Dec 4 13:25
> /opt/win4linpro/lib/sys/libcrypto.so.0.9.7

So both libcrypto.so files are version 0.9.7
but one has EVP_idea_cbc and the other doesn't.
Somebody screwed up.

I think I'd remove the win4lin library from your ld.so
and use a script to start win4lin that sets LD_LIBRARY_PATH.

On Tue, 08 Jan 2008 14:07:39 GMT, Dan Espen
wrote:
> Crashdamage <03z1krd7@nospam.invalid> writes:

>> On Mon, 07 Jan 2008 15:15:16 GMT, Dan Espen
>> wrote:
>>> Crashdamage <03z1krd7@nospam.invalid> writes:
>>
>>>> On Sun, 06 Jan 2008 17:57:57 -0500, David W. Hodgins
>>>> wrote:
>>>>> On Sun, 06 Jan 2008 17:24:08 -0500, Crashdamage <03z1krd7@nospam.invalid> wrote:
>>>>
>>>>>> Anyway, OK, the link libcrypto.so takes care of resolving the EVP's.
>>>>>> But how do I fix this? There must be a way - it's not like everything
>>>>>> is trashed. Seems like it should be fairly simple and doable - if I
>>>>>> knew what to do.
>>>>
>>>>> Looks like the problem may be due to the order the directories are being
>>>>> searched. Change /etc/ld.so.conf so that /lib is searched first, followed
>>>>> by /usr/lib, followed by anything added by other applications. Then
>>>>> run ldconfig, and then confirm with ldd that the correct version of libcrypt
>>>>> is being selected.
>>>>
>>>> My existing ld.so.conf doesn't search /lib at at all, but it hasn't
>>>> changed since Feb 2007 either so I don't think that's it. Here it is:
>>>>
>>>> include ld.so.conf.d/*.conf
>>>> /usr/X11R6/lib
>>>> /usr/lib/qt3/lib
>>>> /opt/win4linpro/lib/sys
>>>>
>>>> Are you saying I should just add '/lib' to the top of the directory
>>>> list? Isn't that too general?
>>
>>> You could, at least to see what happens.
>>> You could also export LD_LIBRARY_PATH to see what that does.
>>> But...
>>
>>>> At present, running '# ldconfig' returns nothing. Honestly, I've never
>>>> run that command. What exactly does it do and what should it return?
>>
>>> Try "man ldconfig".
>>> It's normally run when you install a package.
>>> Try:
>>
>>> ldconfig -v
>>
>>> if you want feedback.
>>
>> That gave *lots* of feedback...
>>
>>>> The version of libcrypt installed never changed, and it's still the
>>>> original. I carefully rolled all packages I did change back and made
>>>> sure only one version (the previous one) was still installed. Still,
>>>> *something* is not quite as it was.
>>
>>> Actually, normal shared library versioning should be protecting you.
>>> Perhaps you should post the output of:
>>
>>> ls -l /usr/lib/libcrypt*
>>
>> $ ls -l /usr/lib/libcrypt*
>> lrwxrwxrwx 1 root root 38 Jan 7 23:38 /usr/lib/libcrypto.so ->
>> ../../../../usr/lib/libcrypto.so.0.9.7*
>> -rwxr-xr-x 1 root root 1038480 Oct 10 2005
>> /usr/lib/libcrypto.so.0.9.7*
>> lrwxrwxrwx 1 root root 33 Jan 7 23:38 /usr/lib/libcrypt.so ->
>> ../../../../lib/libcrypt-2.3.3.so*
>>
>> Some of the above are very recent because I've been replacing stuff from
>> backups tonight trying to make sure everything is rolled back to
>> *exactly* as it was before all this started.
>>
>>> ls -l /opt/win4linpro/lib/sys/libcrypt*
>>
>> $ ls -l /opt/win4linpro/lib/sys/libcrypt*
>> -r--r--r-- 1 root bin 1029704 Dec 4 13:25
>> /opt/win4linpro/lib/sys/libcrypto.so.0.9.7

> So both libcrypto.so files are version 0.9.7
> but one has EVP_idea_cbc and the other doesn't.
> Somebody screwed up.

Actually, I'm sure *both* do. It somehow is getting the
'EVP_idea_cdc' error from somewhere else - it *must* be - because the
/usr/lib/libcrypto.so file that is presently in the system was copied
from backups made long before my problems. But...

$ nm -D /usr/lib/libcrypto.so | grep EVP_idea
00088aa0 T EVP_idea_cbc
00090920 T EVP_idea_cfb
00088ac0 T EVP_idea_cfb64
00088b00 T EVP_idea_ecb
00088ae0 T EVP_idea_ofb

Want more proof? How about this:

$ nm -D /data2/Backups/usr/lib/libcrypto.so | grep EVP_idea
00088aa0 T EVP_idea_cbc
00090920 T EVP_idea_cfb
00088ac0 T EVP_idea_cfb64
00088b00 T EVP_idea_ecb
00088ae0 T EVP_idea_ofb

That backup dates from Oct 2006. So it's been in there all along, just
never caused trouble. so *something* else is still different.

To be as certain as possible that everything I changed is rolled back to
as it was, I've even manually copied all the files from backups to the
few packages that were changed when trying to install Firefox 3b2
(remember - that's what started all this). I absolutely can't figure
out what is still different than before but something is. I still get
stuff like this (whether calling Firefox 2 or 3):

$ firefox
/usr/local/firefox/firefox-bin: symbol lookup error:
/usr/lib/libssl.so.0.9.7: undefined symbol: EVP_idea_cbc

A few other things are broken - sendmail, so no sending with Mutt; perl,
so no urpmi; Grip, Thunderbird, etc.

> I think I'd remove the win4lin library from your ld.so

Made no difference. Win4LinPro even seems to work just the same.

Thanks. This one really has me buggered...and this box borked...

--
Registered Linux user #266531

Crashdamage <03z1krd7@nospam.invalid> writes:

> On Tue, 08 Jan 2008 14:07:39 GMT, Dan Espen
> wrote:
>> Crashdamage <03z1krd7@nospam.invalid> writes:
>
>>> On Mon, 07 Jan 2008 15:15:16 GMT, Dan Espen
>>> wrote:
>>>> Crashdamage <03z1krd7@nospam.invalid> writes:
>>>
>>>>> On Sun, 06 Jan 2008 17:57:57 -0500, David W. Hodgins
>>>>> wrote:
>>>>>> On Sun, 06 Jan 2008 17:24:08 -0500, Crashdamage <03z1krd7@nospam.invalid> wrote:
>>>>>
>>>>>>> Anyway, OK, the link libcrypto.so takes care of resolving the EVP's.
>>>>>>> But how do I fix this? There must be a way - it's not like everything
>>>>>>> is trashed. Seems like it should be fairly simple and doable - if I
>>>>>>> knew what to do.
>>>>>
>>>>>> Looks like the problem may be due to the order the directories are being
>>>>>> searched. Change /etc/ld.so.conf so that /lib is searched first, followed
>>>>>> by /usr/lib, followed by anything added by other applications. Then
>>>>>> run ldconfig, and then confirm with ldd that the correct version of libcrypt
>>>>>> is being selected.
>>>>>
>>>>> My existing ld.so.conf doesn't search /lib at at all, but it hasn't
>>>>> changed since Feb 2007 either so I don't think that's it. Here it is:
>>>>>
>>>>> include ld.so.conf.d/*.conf
>>>>> /usr/X11R6/lib
>>>>> /usr/lib/qt3/lib
>>>>> /opt/win4linpro/lib/sys
>>>>>
>>>>> Are you saying I should just add '/lib' to the top of the directory
>>>>> list? Isn't that too general?
>>>
>>>> You could, at least to see what happens.
>>>> You could also export LD_LIBRARY_PATH to see what that does.
>>>> But...
>>>
>>>>> At present, running '# ldconfig' returns nothing. Honestly, I've never
>>>>> run that command. What exactly does it do and what should it return?
>>>
>>>> Try "man ldconfig".
>>>> It's normally run when you install a package.
>>>> Try:
>>>
>>>> ldconfig -v
>>>
>>>> if you want feedback.
>>>
>>> That gave *lots* of feedback...
>>>
>>>>> The version of libcrypt installed never changed, and it's still the
>>>>> original. I carefully rolled all packages I did change back and made
>>>>> sure only one version (the previous one) was still installed. Still,
>>>>> *something* is not quite as it was.
>>>
>>>> Actually, normal shared library versioning should be protecting you.
>>>> Perhaps you should post the output of:
>>>
>>>> ls -l /usr/lib/libcrypt*
>>>
>>> $ ls -l /usr/lib/libcrypt*
>>> lrwxrwxrwx 1 root root 38 Jan 7 23:38 /usr/lib/libcrypto.so ->
>>> ../../../../usr/lib/libcrypto.so.0.9.7*
>>> -rwxr-xr-x 1 root root 1038480 Oct 10 2005
>>> /usr/lib/libcrypto.so.0.9.7*
>>> lrwxrwxrwx 1 root root 33 Jan 7 23:38 /usr/lib/libcrypt.so ->
>>> ../../../../lib/libcrypt-2.3.3.so*
>>>
>>> Some of the above are very recent because I've been replacing stuff from
>>> backups tonight trying to make sure everything is rolled back to
>>> *exactly* as it was before all this started.
>>>
>>>> ls -l /opt/win4linpro/lib/sys/libcrypt*
>>>
>>> $ ls -l /opt/win4linpro/lib/sys/libcrypt*
>>> -r--r--r-- 1 root bin 1029704 Dec 4 13:25
>>> /opt/win4linpro/lib/sys/libcrypto.so.0.9.7
>
>> So both libcrypto.so files are version 0.9.7
>> but one has EVP_idea_cbc and the other doesn't.
>> Somebody screwed up.
>
> Actually, I'm sure *both* do. It somehow is getting the
> 'EVP_idea_cdc' error from somewhere else - it *must* be - because the
> /usr/lib/libcrypto.so file that is presently in the system was copied
> from backups made long before my problems. But...
>
> $ nm -D /usr/lib/libcrypto.so | grep EVP_idea
> 00088aa0 T EVP_idea_cbc
> 00090920 T EVP_idea_cfb
> 00088ac0 T EVP_idea_cfb64
> 00088b00 T EVP_idea_ecb
> 00088ae0 T EVP_idea_ofb
>
> Want more proof? How about this:
>
> $ nm -D /data2/Backups/usr/lib/libcrypto.so | grep EVP_idea
> 00088aa0 T EVP_idea_cbc
> 00090920 T EVP_idea_cfb
> 00088ac0 T EVP_idea_cfb64
> 00088b00 T EVP_idea_ecb
> 00088ae0 T EVP_idea_ofb

You didn't try:

nm -D /opt/win4linpro/lib/sys/libcrypto.so | grep EVP_idea

That's the one ldd said it was using when it couldn't resolve
the symbol.

On Wed, 09 Jan 2008 03:02:05 GMT, Dan Espen
wrote:
> Crashdamage <03z1krd7@nospam.invalid> writes:

>> On Tue, 08 Jan 2008 14:07:39 GMT, Dan Espen
>> wrote:
>>> Crashdamage <03z1krd7@nospam.invalid> writes:
>>
>>>> On Mon, 07 Jan 2008 15:15:16 GMT, Dan Espen
>>>> wrote:
>>>>> Crashdamage <03z1krd7@nospam.invalid> writes:
>>>>
>>>>>> On Sun, 06 Jan 2008 17:57:57 -0500, David W. Hodgins
>>>>>> wrote:
>>>>>>> On Sun, 06 Jan 2008 17:24:08 -0500, Crashdamage <03z1krd7@nospam.invalid> wrote:
>>>>>>
>>>>>>>> Anyway, OK, the link libcrypto.so takes care of resolving the EVP's.
>>>>>>>> But how do I fix this? There must be a way - it's not like everything
>>>>>>>> is trashed. Seems like it should be fairly simple and doable - if I
>>>>>>>> knew what to do.
>>>>>>
>>>>>>> Looks like the problem may be due to the order the directories are being
>>>>>>> searched. Change /etc/ld.so.conf so that /lib is searched first, followed
>>>>>>> by /usr/lib, followed by anything added by other applications. Then
>>>>>>> run ldconfig, and then confirm with ldd that the correct version of libcrypt
>>>>>>> is being selected.
>>>>>>
>>>>>> My existing ld.so.conf doesn't search /lib at at all, but it hasn't
>>>>>> changed since Feb 2007 either so I don't think that's it. Here it is:
>>>>>>
>>>>>> include ld.so.conf.d/*.conf
>>>>>> /usr/X11R6/lib
>>>>>> /usr/lib/qt3/lib
>>>>>> /opt/win4linpro/lib/sys
>>>>>>
>>>>>> Are you saying I should just add '/lib' to the top of the directory
>>>>>> list? Isn't that too general?
>>>>
>>>>> You could, at least to see what happens.
>>>>> You could also export LD_LIBRARY_PATH to see what that does.
>>>>> But...
>>>>
>>>>>> At present, running '# ldconfig' returns nothing. Honestly, I've never
>>>>>> run that command. What exactly does it do and what should it return?
>>>>
>>>>> Try "man ldconfig".
>>>>> It's normally run when you install a package.
>>>>> Try:
>>>>
>>>>> ldconfig -v
>>>>
>>>>> if you want feedback.
>>>>
>>>> That gave *lots* of feedback...
>>>>
>>>>>> The version of libcrypt installed never changed, and it's still the
>>>>>> original. I carefully rolled all packages I did change back and made
>>>>>> sure only one version (the previous one) was still installed. Still,
>>>>>> *something* is not quite as it was.
>>>>
>>>>> Actually, normal shared library versioning should be protecting you.
>>>>> Perhaps you should post the output of:
>>>>
>>>>> ls -l /usr/lib/libcrypt*
>>>>
>>>> $ ls -l /usr/lib/libcrypt*
>>>> lrwxrwxrwx 1 root root 38 Jan 7 23:38 /usr/lib/libcrypto.so ->
>>>> ../../../../usr/lib/libcrypto.so.0.9.7*
>>>> -rwxr-xr-x 1 root root 1038480 Oct 10 2005
>>>> /usr/lib/libcrypto.so.0.9.7*
>>>> lrwxrwxrwx 1 root root 33 Jan 7 23:38 /usr/lib/libcrypt.so ->
>>>> ../../../../lib/libcrypt-2.3.3.so*
>>>>
>>>> Some of the above are very recent because I've been replacing stuff from
>>>> backups tonight trying to make sure everything is rolled back to
>>>> *exactly* as it was before all this started.
>>>>
>>>>> ls -l /opt/win4linpro/lib/sys/libcrypt*
>>>>
>>>> $ ls -l /opt/win4linpro/lib/sys/libcrypt*
>>>> -r--r--r-- 1 root bin 1029704 Dec 4 13:25
>>>> /opt/win4linpro/lib/sys/libcrypto.so.0.9.7
>>
>>> So both libcrypto.so files are version 0.9.7
>>> but one has EVP_idea_cbc and the other doesn't.
>>> Somebody screwed up.
>>
>> Actually, I'm sure *both* do. It somehow is getting the
>> 'EVP_idea_cdc' error from somewhere else - it *must* be - because the
>> /usr/lib/libcrypto.so file that is presently in the system was copied
>> from backups made long before my problems. But...
>>
>> $ nm -D /usr/lib/libcrypto.so | grep EVP_idea
>> 00088aa0 T EVP_idea_cbc
>> 00090920 T EVP_idea_cfb
>> 00088ac0 T EVP_idea_cfb64
>> 00088b00 T EVP_idea_ecb
>> 00088ae0 T EVP_idea_ofb
>>
>> Want more proof? How about this:
>>
>> $ nm -D /data2/Backups/usr/lib/libcrypto.so | grep EVP_idea
>> 00088aa0 T EVP_idea_cbc
>> 00090920 T EVP_idea_cfb
>> 00088ac0 T EVP_idea_cfb64
>> 00088b00 T EVP_idea_ecb
>> 00088ae0 T EVP_idea_ofb

> You didn't try:

> nm -D /opt/win4linpro/lib/sys/libcrypto.so | grep EVP_idea

> That's the one ldd said it was using when it couldn't resolve
> the symbol.

Well, I did, I just didn't post the output because I didn't think it was
meaningful:

$ nm -D /opt/win4linpro/lib/sys/libcrypto.so | grep EVP_idea
nm: '/opt/win4linpro/lib/sys/libcrypto.so': No such file

Also, I noticed that even though I'd removed '/opt/win4linpro/lib/sys'
from ld.so.conf, when I ran Win4LinPro that line was atutomatically
restored. Not sure what it could have to do with the symbol error, I
just don't see a connection there. Just I took it out, Win4Lin needed
it and put it back. I think that's irrelevent to the problem, nothing
was changed in regards to Win4Lin in trying to install Firefox3. I
even uninstalled the Win4LinPro rpm and the EVA symbol error remained.

Still can't figure what I have not put back as it was before.
--
Registered Linux user #266531

Crashdamage <03z1krd7@nospam.invalid> writes:

> On Wed, 09 Jan 2008 03:02:05 GMT, Dan Espen
> wrote:
>> Crashdamage <03z1krd7@nospam.invalid> writes:
>
>>> On Tue, 08 Jan 2008 14:07:39 GMT, Dan Espen
>>> wrote:
>>>> Crashdamage <03z1krd7@nospam.invalid> writes:
>>>
>>>>> On Mon, 07 Jan 2008 15:15:16 GMT, Dan Espen
>>>>> wrote:
>>>>>> Crashdamage <03z1krd7@nospam.invalid> writes:
>>>>>
>>>>>>> On Sun, 06 Jan 2008 17:57:57 -0500, David W. Hodgins
>>>>>>> wrote:
>>>>>>>> On Sun, 06 Jan 2008 17:24:08 -0500, Crashdamage <03z1krd7@nospam.invalid> wrote:
>>>>>>>
>>>>>>>>> Anyway, OK, the link libcrypto.so takes care of resolving the EVP's.
>>>>>>>>> But how do I fix this? There must be a way - it's not like everything
>>>>>>>>> is trashed. Seems like it should be fairly simple and doable - if I
>>>>>>>>> knew what to do.
>>>>>>>
>>>>>>>> Looks like the problem may be due to the order the directories are being
>>>>>>>> searched. Change /etc/ld.so.conf so that /lib is searched first, followed
>>>>>>>> by /usr/lib, followed by anything added by other applications. Then
>>>>>>>> run ldconfig, and then confirm with ldd that the correct version of libcrypt
>>>>>>>> is being selected.
>>>>>>>
>>>>>>> My existing ld.so.conf doesn't search /lib at at all, but it hasn't
>>>>>>> changed since Feb 2007 either so I don't think that's it. Here it is:
>>>>>>>
>>>>>>> include ld.so.conf.d/*.conf
>>>>>>> /usr/X11R6/lib
>>>>>>> /usr/lib/qt3/lib
>>>>>>> /opt/win4linpro/lib/sys
>>>>>>>
>>>>>>> Are you saying I should just add '/lib' to the top of the directory
>>>>>>> list? Isn't that too general?
>>>>>
>>>>>> You could, at least to see what happens.
>>>>>> You could also export LD_LIBRARY_PATH to see what that does.
>>>>>> But...
>>>>>
>>>>>>> At present, running '# ldconfig' returns nothing. Honestly, I've never
>>>>>>> run that command. What exactly does it do and what should it return?
>>>>>
>>>>>> Try "man ldconfig".
>>>>>> It's normally run when you install a package.
>>>>>> Try:
>>>>>
>>>>>> ldconfig -v
>>>>>
>>>>>> if you want feedback.
>>>>>
>>>>> That gave *lots* of feedback...
>>>>>
>>>>>>> The version of libcrypt installed never changed, and it's still the
>>>>>>> original. I carefully rolled all packages I did change back and made
>>>>>>> sure only one version (the previous one) was still installed. Still,
>>>>>>> *something* is not quite as it was.
>>>>>
>>>>>> Actually, normal shared library versioning should be protecting you.
>>>>>> Perhaps you should post the output of:
>>>>>
>>>>>> ls -l /usr/lib/libcrypt*
>>>>>
>>>>> $ ls -l /usr/lib/libcrypt*
>>>>> lrwxrwxrwx 1 root root 38 Jan 7 23:38 /usr/lib/libcrypto.so ->
>>>>> ../../../../usr/lib/libcrypto.so.0.9.7*
>>>>> -rwxr-xr-x 1 root root 1038480 Oct 10 2005
>>>>> /usr/lib/libcrypto.so.0.9.7*
>>>>> lrwxrwxrwx 1 root root 33 Jan 7 23:38 /usr/lib/libcrypt.so ->
>>>>> ../../../../lib/libcrypt-2.3.3.so*
>>>>>
>>>>> Some of the above are very recent because I've been replacing stuff from
>>>>> backups tonight trying to make sure everything is rolled back to
>>>>> *exactly* as it was before all this started.
>>>>>
>>>>>> ls -l /opt/win4linpro/lib/sys/libcrypt*
>>>>>
>>>>> $ ls -l /opt/win4linpro/lib/sys/libcrypt*
>>>>> -r--r--r-- 1 root bin 1029704 Dec 4 13:25
>>>>> /opt/win4linpro/lib/sys/libcrypto.so.0.9.7
>>>
>>>> So both libcrypto.so files are version 0.9.7
>>>> but one has EVP_idea_cbc and the other doesn't.
>>>> Somebody screwed up.
>>>
>>> Actually, I'm sure *both* do. It somehow is getting the
>>> 'EVP_idea_cdc' error from somewhere else - it *must* be - because the
>>> /usr/lib/libcrypto.so file that is presently in the system was copied
>>> from backups made long before my problems. But...
>>>
>>> $ nm -D /usr/lib/libcrypto.so | grep EVP_idea
>>> 00088aa0 T EVP_idea_cbc
>>> 00090920 T EVP_idea_cfb
>>> 00088ac0 T EVP_idea_cfb64
>>> 00088b00 T EVP_idea_ecb
>>> 00088ae0 T EVP_idea_ofb
>>>
>>> Want more proof? How about this:
>>>
>>> $ nm -D /data2/Backups/usr/lib/libcrypto.so | grep EVP_idea
>>> 00088aa0 T EVP_idea_cbc
>>> 00090920 T EVP_idea_cfb
>>> 00088ac0 T EVP_idea_cfb64
>>> 00088b00 T EVP_idea_ecb
>>> 00088ae0 T EVP_idea_ofb
>
>> You didn't try:
>
>> nm -D /opt/win4linpro/lib/sys/libcrypto.so | grep EVP_idea
>
>> That's the one ldd said it was using when it couldn't resolve
>> the symbol.
>
> Well, I did, I just didn't post the output because I didn't think it was
> meaningful:
>
> $ nm -D /opt/win4linpro/lib/sys/libcrypto.so | grep EVP_idea
> nm: '/opt/win4linpro/lib/sys/libcrypto.so': No such file

Get the name of the library right. I don't have the whole thread
here but it may need a version number at the end.

> Also, I noticed that even though I'd removed '/opt/win4linpro/lib/sys'
> from ld.so.conf, when I ran Win4LinPro that line was atutomatically
> restored. Not sure what it could have to do with the symbol error, I
> just don't see a connection there. Just I took it out, Win4Lin needed
> it and put it back. I think that's irrelevent to the problem, nothing
> was changed in regards to Win4Lin in trying to install Firefox3. I
> even uninstalled the Win4LinPro rpm and the EVA symbol error remained.
>
> Still can't figure what I have not put back as it was before.

There is a libcrypto in win4lin that lacks the symbols shown above.
That's why you get those error messages.

On Wed, 09 Jan 2008 15:11:41 GMT, Dan Espen
wrote:
> Crashdamage <03z1krd7@nospam.invalid> writes:
(snip)
>>>>> So both libcrypto.so files are version 0.9.7
>>>>> but one has EVP_idea_cbc and the other doesn't.
>>>>> Somebody screwed up.

Seems you were right about this all along...see below...
(snip)
>>> You didn't try:
>>
>>> nm -D /opt/win4linpro/lib/sys/libcrypto.so | grep EVP_idea
>>
>>> That's the one ldd said it was using when it couldn't resolve
>>> the symbol.
>>
>> Well, I did, I just didn't post the output because I didn't think it was
>> meaningful:
>>
>> $ nm -D /opt/win4linpro/lib/sys/libcrypto.so | grep EVP_idea
>> nm: '/opt/win4linpro/lib/sys/libcrypto.so': No such file

> Get the name of the library right. I don't have the whole thread
> here but it may need a version number at the end.

Sorry, my goof, I was just really tired at the time:

$ nm -D /opt/win4linpro/lib/sys/libcrypt.so.0.9.7 | grep EVP_idea
$

Which got me thinking...

> There is a libcrypto in win4lin that lacks the symbols shown above.
> That's why you get those error messages.

I'm seeing what you mean a little clearer, but I don't understand how
that could be since that file is unchanged from before. But I renamed
/sys (from the above) to get it out of the way and - VOILA!! Firefox
lives!! And of course some other things.

Just to test, I uninstall/reinstall Win4LinPro to get a fresh set of
files - Firefox dies and the EVP symbol error is back.

So I checked some old Win4Lin backups and under /opt/win4linpro/lib/sys
libcrypt.so.0.9.7 is not there - in fact there's not even a /sys. On a
hunch it may not be needed at all, I just delete libcrypt.so.0.9.7 from
/opt/win4linpro/lib/sys and try Win4LinPro - it runs, and as far as I
can tell just as before, which is to say pretty nice.

So THANKS!!! I'm not a programmer and certainly no guru. I've used
Linux for about 6 years, but I'm a user, not a programmer. I can't
quite get my pinhead around what all this means exactly, but it works
and that's the bottom line.

I am curious what libcrypt.so.0.9.7 actually is supposed to do in
Win4LinPro. And I'm *very* curious what could still be changed on the
system from before. Something has to be. It can't be a Win4Lin
problem, not really. The exact same Win4Lin rpm never caused this or
any other conflicts or problems before my little Firefox3 adventure.
If you could explain all this a little clearer or give me a hint on how
to track down what is still changed, I'd buy you a few if you're ever in
Kansas City.

Thanks again for the help!
--
Registered Linux user #266531

Crashdamage <03z1krd7@nospam.invalid> writes:

> On Wed, 09 Jan 2008 15:11:41 GMT, Dan Espen
> wrote:
>> Crashdamage <03z1krd7@nospam.invalid> writes:
> (snip)
>>>>>> So both libcrypto.so files are version 0.9.7
>>>>>> but one has EVP_idea_cbc and the other doesn't.
>>>>>> Somebody screwed up.
>
> Seems you were right about this all along...see below...
> (snip)
>>>> You didn't try:
>>>
>>>> nm -D /opt/win4linpro/lib/sys/libcrypto.so | grep EVP_idea
>>>
>>>> That's the one ldd said it was using when it couldn't resolve
>>>> the symbol.
>>>
>>> Well, I did, I just didn't post the output because I didn't think it was
>>> meaningful:
>>>
>>> $ nm -D /opt/win4linpro/lib/sys/libcrypto.so | grep EVP_idea
>>> nm: '/opt/win4linpro/lib/sys/libcrypto.so': No such file
>
>> Get the name of the library right. I don't have the whole thread
>> here but it may need a version number at the end.
>
> Sorry, my goof, I was just really tired at the time:
>
> $ nm -D /opt/win4linpro/lib/sys/libcrypt.so.0.9.7 | grep EVP_idea
> $
>
> Which got me thinking...
>
>> There is a libcrypto in win4lin that lacks the symbols shown above.
>> That's why you get those error messages.
>
> I'm seeing what you mean a little clearer, but I don't understand how
> that could be since that file is unchanged from before. But I renamed
> /sys (from the above) to get it out of the way and - VOILA!! Firefox
> lives!! And of course some other things.
>
> Just to test, I uninstall/reinstall Win4LinPro to get a fresh set of
> files - Firefox dies and the EVP symbol error is back.
>
> So I checked some old Win4Lin backups and under /opt/win4linpro/lib/sys
> libcrypt.so.0.9.7 is not there - in fact there's not even a /sys. On a
> hunch it may not be needed at all, I just delete libcrypt.so.0.9.7 from
> /opt/win4linpro/lib/sys and try Win4LinPro - it runs, and as far as I
> can tell just as before, which is to say pretty nice.
>
> So THANKS!!! I'm not a programmer and certainly no guru. I've used
> Linux for about 6 years, but I'm a user, not a programmer. I can't
> quite get my pinhead around what all this means exactly, but it works
> and that's the bottom line.
>
> I am curious what libcrypt.so.0.9.7 actually is supposed to do in
> Win4LinPro. And I'm *very* curious what could still be changed on the
> system from before. Something has to be. It can't be a Win4Lin
> problem, not really. The exact same Win4Lin rpm never caused this or
> any other conflicts or problems before my little Firefox3 adventure.
> If you could explain all this a little clearer or give me a hint on how
> to track down what is still changed, I'd buy you a few if you're ever in
> Kansas City.

Hi again Crash,

I'll try.

nm shows you the symbols in a shared library.

ldd shows you the shared libraries an executable will use.

ldconf tells the system what paths to search and what order to search for
shared libraries.

You were getting an error message from firefox saying it couldn't
find the symbols it needed in one of it's shared libraries.

When you ran ldd against firefox it showed you which libraries
it would load.

I looked thru those libraries on my system to find out which one
was supposed to resolve EVP_idea...

Also when I saw that your firefox was loading a library from /opt/win4lin
it wasn't hard to guess which library had the missing symbols.

So, we saw that libcrypt.so.0.9.7 is the bad library.

When shared libraries change in such a way that they provide new
external symbols, they are supposed to get a new version
number. I can't explain why win4lin is distributing libcrypt 0.9.7
with missing symbols. They shouldn't distribute commonly available
libraries, but if they really have to, they should have changed the
version number. Somebody screwed up.

On Thu, 10 Jan 2008 02:51:12 GMT, Dan Espen
wrote:
> Crashdamage <03z1krd7@nospam.invalid> writes:

>> On Wed, 09 Jan 2008 15:11:41 GMT, Dan Espen
>> wrote:
>>> Crashdamage <03z1krd7@nospam.invalid> writes:
>> (snip)
>>>>>>> So both libcrypto.so files are version 0.9.7
>>>>>>> but one has EVP_idea_cbc and the other doesn't.
>>>>>>> Somebody screwed up.
>>
>> Seems you were right about this all along...see below...
>> (snip)
>>>>> You didn't try:
>>>>
>>>>> nm -D /opt/win4linpro/lib/sys/libcrypto.so | grep EVP_idea
>>>>
>>>>> That's the one ldd said it was using when it couldn't resolve
>>>>> the symbol.
>>>>
>>>> Well, I did, I just didn't post the output because I didn't think it was
>>>> meaningful:
>>>>
>>>> $ nm -D /opt/win4linpro/lib/sys/libcrypto.so | grep EVP_idea
>>>> nm: '/opt/win4linpro/lib/sys/libcrypto.so': No such file
>>
>>> Get the name of the library right. I don't have the whole thread
>>> here but it may need a version number at the end.
>>
>> Sorry, my goof, I was just really tired at the time:
>>
>> $ nm -D /opt/win4linpro/lib/sys/libcrypt.so.0.9.7 | grep EVP_idea
>> $
>>
>> Which got me thinking...
>>
>>> There is a libcrypto in win4lin that lacks the symbols shown above.
>>> That's why you get those error messages.
>>
>> I'm seeing what you mean a little clearer, but I don't understand how
>> that could be since that file is unchanged from before. But I renamed
>> /sys (from the above) to get it out of the way and - VOILA!! Firefox
>> lives!! And of course some other things.
>>
>> Just to test, I uninstall/reinstall Win4LinPro to get a fresh set of
>> files - Firefox dies and the EVP symbol error is back.
>>
>> So I checked some old Win4Lin backups and under /opt/win4linpro/lib/sys
>> libcrypt.so.0.9.7 is not there - in fact there's not even a /sys. On a
>> hunch it may not be needed at all, I just delete libcrypt.so.0.9.7 from
>> /opt/win4linpro/lib/sys and try Win4LinPro - it runs, and as far as I
>> can tell just as before, which is to say pretty nice.
>>
>> So THANKS!!! I'm not a programmer and certainly no guru. I've used
>> Linux for about 6 years, but I'm a user, not a programmer. I can't
>> quite get my pinhead around what all this means exactly, but it works
>> and that's the bottom line.
>>
>> I am curious what libcrypt.so.0.9.7 actually is supposed to do in
>> Win4LinPro. And I'm *very* curious what could still be changed on the
>> system from before. Something has to be. It can't be a Win4Lin
>> problem, not really. The exact same Win4Lin rpm never caused this or
>> any other conflicts or problems before my little Firefox3 adventure.
>> If you could explain all this a little clearer or give me a hint on how
>> to track down what is still changed, I'd buy you a few if you're ever in
>> Kansas City.

> Hi again Crash,

> I'll try.

> nm shows you the symbols in a shared library.

> ldd shows you the shared libraries an executable will use.

> ldconf tells the system what paths to search and what order to search for
> shared libraries.

> You were getting an error message from firefox saying it couldn't
> find the symbols it needed in one of it's shared libraries.

> When you ran ldd against firefox it showed you which libraries
> it would load.

> I looked thru those libraries on my system to find out which one
> was supposed to resolve EVP_idea...

> Also when I saw that your firefox was loading a library from /opt/win4lin
> it wasn't hard to guess which library had the missing symbols.

> So, we saw that libcrypt.so.0.9.7 is the bad library.

> When shared libraries change in such a way that they provide new
> external symbols, they are supposed to get a new version
> number. I can't explain why win4lin is distributing libcrypt 0.9.7
> with missing symbols. They shouldn't distribute commonly available
> libraries, but if they really have to, they should have changed the
> version number. Somebody screwed up.

OK, thanks. I'd finally gotten a fair grip on this before, but that
states it nice and clear. You've definetly taught me some things.
There's just one thing that still bothers me...I hate to belabor this
but...

You said, and I do know what you mean:
> When shared libraries change in such a way that they provide new
> external symbols, they are supposed to get a new version
> number. I can't explain why win4lin is distributing libcrypt 0.9.7
> with missing symbols.

My point is, regardless that clearly "Somebody screwed up" there's a
shared library located *outside* of Win4Lin that must still be changed
from before the attempted Firefox3 install, causing the
libcrypto.so.0.9.7 file located *inside* Win4Lin to generate the
missing symbol errors. This must be, because the presence of that
libcrypto.so file in Win4Lin was harmless before.

Far as I can tell, I've put everything back to the original condition
including, of course, Firefox2, yet obviously not quite. So how do I
find what's still changed from before? Or is that even easily
possible? Not a big deal, 'cause Win4LinPro doesn't seem to miss
libcrypto.so. I guess whatever function it serves I'm not using. And
when I install an updated version of W4L I can simply delete it again
to bring all the stars back into alignment. I'm more curious, just
like to learn how to do it.

--
Registered Linux user #266531