[SOLVED] New openssl 1.0.0 breaks packages that depend on 0.9.8

veox · 2010-04-16 09:14:10

uname -a
Linux <hostname> 2.6.32-ARCH #1 SMP PREEMPT <date> x86_64 Intel(R) Core(TM)2 Duo CPU T5670 @ 1.80GHz GenuineIntel GNU/Linux

This is more like a community warning - only do a full system upgrade if you haven't got the new openssl yet.

After updating openssl (separately from all the other packages) I was no longer able to use binaries that depend on libraries libcrypto and libssl version 0.9.8. These include, most importantly, pacman, also wget, curl, ssh, and many others.

A temporary fix is

cd /usr/lib/
sudo ln -s ./libssl.so.1.0.0 libssl.so.0.9.8
sudo ln -s ./libcrypto.so.1.0.0 libcrypto.so.0.9.8

This makes pacman operational again, until a package linked against 1.0.0 propagates through the servers. Packages for wget and ssh already did.

Last edited by veox (2010-04-16 11:35:07)

flamelab · 2010-04-16 09:18:43

Wait, wait, wait.

1. Use a correct mirror, for example mir.archlinux.fr, FULLY UPDATE: pacman -Syu. Do not update only one package, but your entire system with pacman -Syu.
2. You must *never* do such symlinks.
2.b and propose them on forums ...
3. If you have any AUR package that may depend on new libssl, rebuild it.

Last edited by flamelab (2010-04-16 09:19:38)

Allan · 2010-04-16 09:19:13

1) This is old... the move happened over a week ago.
2) symlinking is known to break things

All mirrors should have caught up by now. If yours has not, consider it dead and change to a better one. Any AUR packages that need rebuilt are your own job.

Edit: LOL! flamelab gave the same list

veox · 2010-04-16 11:33:07

Thanks flamelab, Allan.

Yes, actually, I know from personal experience symlinks like this are bad. However, pacman has become unoperational without them.

Changing the mirror didn't help, so I assumed the packages haven't propagated. However, looking at the dates now I understand the assumption was wrong. Still, upgrading pacman doesn't help, it still depends on 0.9.8 (ldd `where pacman`).

To fix this now, I:
- added the symlinks as shown above;
- updated libfetch and bsdtar that are required for the build process;
- removed the symlinks;
- built pacman from ABS;
- added the symlinks;
- updated pacman locally (pacman -U);
- removed the symlinks.

I have to say all this voodoo happened because I have limited traffic and doing a full system upgrade several times a month is not a sane option. It's my trouble, of course.

Last edited by veox (2010-04-16 11:35:43)

B-Con · 2010-04-17 03:56:27

I encountered this problem today because my system crashed in the middle of a 40+ package system upgrade. libssl was installed and the system crashed before the others could. The temporarly symlink allowed me to use pacman to finish the upgrade (then obviously I could remove the symlinks).

towelfox · 2010-04-17 12:45:58

flamelab wrote:

Wait, wait, wait.
1. Use a correct mirror, for example mir.archlinux.fr, FULLY UPDATE: pacman -Syu. Do not update only one package, but your entire system with pacman -Syu.
2. You must *never* do such symlinks.
2.b and propose them on forums ...
3. If you have any AUR package that may depend on new libssl, rebuild it.

Never say never. My upgrade was interrupted and pacman was broken so the only solution was to symlink, upgrade, remove symlink. I don't think there's anything wrong with that.

Spacenick · 2010-04-17 13:09:37

Yeah that never say never has some point, i had to symlink libpng to make Webpack ISE (a proprietary IDE for FPGA development) runnable. Sometimes you just have no other chance

flamelab · 2010-04-17 13:19:20

towelfox wrote:

flamelab wrote:
Wait, wait, wait.
1. Use a correct mirror, for example mir.archlinux.fr, FULLY UPDATE: pacman -Syu. Do not update only one package, but your entire system with pacman -Syu.
2. You must *never* do such symlinks.
2.b and propose them on forums ...
3. If you have any AUR package that may depend on new libssl, rebuild it.
Never say never. My upgrade was interrupted and pacman was broken so the only solution was to symlink, upgrade, remove symlink. I don't think there's anything wrong with that.

Never.

If you want an earlier version, install an appropriate package, like libpng12, libjpeg7 and so more, that provide earlier versions, but without symlinks.

With that way you follow Windows' way though, which have multiple versions of libs in System32 and WinSxS.

Last edited by flamelab (2010-04-17 13:20:44)

loserMcloser · 2010-04-18 06:03:07

Whatever happend to pacman.static ??? Sure would come in handy if/when someone gets themself into this kind of trouble...

czarkoff · 2010-04-27 17:38:14

I have a binary package (with no source available) depending on libssl.so.0.9.8 and libcrypto.so.0.9.8.
After symlinking I get:

$ ldd /usr/lib/wimax/libwpa_wimax_supplicant.so
/usr/lib/wimax/libwpa_wimax_supplicant.so: /usr/lib/libcrypto.so.0.9.8: no version information available (required by /usr/lib/wimax/libwpa_wimax_supplicant.so)
/usr/lib/wimax/libwpa_wimax_supplicant.so: /usr/lib/libssl.so.0.9.8: no version information available (required by /usr/lib/wimax/libwpa_wimax_supplicant.so)
        linux-gate.so.1 =>  (0xb777a000)
        libssl.so.0.9.8 => /usr/lib/libssl.so.0.9.8 (0xb76b6000)
        libcrypto.so.0.9.8 => /usr/lib/libcrypto.so.0.9.8 (0xb753a000)
        libpthread.so.0 => /lib/libpthread.so.0 (0xb7521000)
        libc.so.6 => /lib/libc.so.6 (0xb73d5000)
        libdl.so.2 => /lib/libdl.so.2 (0xb73d0000)
        libz.so.1 => /usr/lib/libz.so.1 (0xb73bb000)
        /lib/ld-linux.so.2 (0xb777b000)

What can I do to solve he problem?

Last edited by czarkoff (2010-04-27 17:39:25)

tomk · 2010-04-27 20:08:13

I've seen that "no version info" message before with binary blobs, but it didn't stop them working. I take it yours is failing?

veox · 2010-04-27 20:32:13

czarkoff, the linking shown above is only a temporary workaround if you broke pacman.

As flamelab wrote, you should install openssl098 if you need the old version of the library. If it's not available, you should make one yourself or request it (in the AUR package requests forum).

Arch Linux

#1 2010-04-16 09:14:10

[SOLVED] New openssl 1.0.0 breaks packages that depend on 0.9.8

#2 2010-04-16 09:18:43

Re: [SOLVED] New openssl 1.0.0 breaks packages that depend on 0.9.8

#3 2010-04-16 09:19:13

Re: [SOLVED] New openssl 1.0.0 breaks packages that depend on 0.9.8

#4 2010-04-16 11:33:07

Re: [SOLVED] New openssl 1.0.0 breaks packages that depend on 0.9.8

#5 2010-04-17 03:56:27

Re: [SOLVED] New openssl 1.0.0 breaks packages that depend on 0.9.8

#6 2010-04-17 12:45:58

Re: [SOLVED] New openssl 1.0.0 breaks packages that depend on 0.9.8

#7 2010-04-17 13:09:37

Re: [SOLVED] New openssl 1.0.0 breaks packages that depend on 0.9.8

#8 2010-04-17 13:19:20

Re: [SOLVED] New openssl 1.0.0 breaks packages that depend on 0.9.8

#9 2010-04-18 06:03:07

Re: [SOLVED] New openssl 1.0.0 breaks packages that depend on 0.9.8

#10 2010-04-27 17:38:14

Re: [SOLVED] New openssl 1.0.0 breaks packages that depend on 0.9.8

#11 2010-04-27 20:08:13

Re: [SOLVED] New openssl 1.0.0 breaks packages that depend on 0.9.8

#12 2010-04-27 20:32:13

Re: [SOLVED] New openssl 1.0.0 breaks packages that depend on 0.9.8

Board footer