[arch-general] pacman changes libcrypt.so.1 symlink
Hi I don't know if it's bug or feature, but it makes me crazy. It begun probably after some pacman upgrade. I'm using blowfish passwords with my archlinux, so my /lib/libcrypt.so.1 points to libxcrypt.so.1 instead of libcrypt-2.7.so from glibc. In my pacman.conf I have NoExtract = lib/libcrypt.so.1. But even though I've made this arrangements everytime when I run pacman -S some_interesting_package (it doesn't have to be glibc, eg libpng is enough) the link gets changed. Any suggestions? Best regards, Lukas '6xx' Jirkovsky
Lukáš Jirkovský wrote:
Hi I don't know if it's bug or feature, but it makes me crazy. It begun probably after some pacman upgrade. I'm using blowfish passwords with my archlinux, so my /lib/libcrypt.so.1 points to libxcrypt.so.1 instead of libcrypt-2.7.so from glibc. In my pacman.conf I have NoExtract = lib/libcrypt.so.1. But even though I've made this arrangements everytime when I run pacman -S some_interesting_package (it doesn't have to be glibc, eg libpng is enough) the link gets changed. Any suggestions?
From what I can tell, it's ldconfig who does this (try running it, it should overwrite your symlink). And pacman runs ldconfig when installing packages. Maybe someone can clarify further why ldconfig does this and if it's possible to prevent it.
Xavier wrote:
Lukáš Jirkovský wrote:
Hi I don't know if it's bug or feature, but it makes me crazy. It begun probably after some pacman upgrade. I'm using blowfish passwords with my archlinux, so my /lib/libcrypt.so.1 points to libxcrypt.so.1 instead of libcrypt-2.7.so from glibc. In my pacman.conf I have NoExtract = lib/libcrypt.so.1. But even though I've made this arrangements everytime when I run pacman -S some_interesting_package (it doesn't have to be glibc, eg libpng is enough) the link gets changed. Any suggestions?
From what I can tell, it's ldconfig who does this (try running it, it should overwrite your symlink). And pacman runs ldconfig when installing packages. Maybe someone can clarify further why ldconfig does this and if it's possible to prevent it.
ldconfig makes sure you are using the most recent version of a certain library and provides a cache for the runtime linker. See man 8 ldconfig. Glenn
I had this same exact problem while either upgrading or installing a package(s) and I simply removed it (which I was almost sure would break something anyway) and reran pacman and it seemed to work fine. Although I probably wouldnt recommend doing it because it could possibly affect one package differently from another. On Wed, 2008-05-07 at 20:28 +0200, RedShift wrote:
Xavier wrote:
Lukáš Jirkovský wrote:
Hi I don't know if it's bug or feature, but it makes me crazy. It begun probably after some pacman upgrade. I'm using blowfish passwords with my archlinux, so my /lib/libcrypt.so.1 points to libxcrypt.so.1 instead of libcrypt-2.7.so from glibc. In my pacman.conf I have NoExtract = lib/libcrypt.so.1. But even though I've made this arrangements everytime when I run pacman -S some_interesting_package (it doesn't have to be glibc, eg libpng is enough) the link gets changed. Any suggestions?
From what I can tell, it's ldconfig who does this (try running it, it should overwrite your symlink). And pacman runs ldconfig when installing packages. Maybe someone can clarify further why ldconfig does this and if it's possible to prevent it.
ldconfig makes sure you are using the most recent version of a certain library and provides a cache for the runtime linker. See man 8 ldconfig.
Glenn
Thanks, so now I've to find some solutions to this. In the worst case I can make ldconfig wrapper. 2008/5/8 Alec Hussey <alec.hussey@madsoft.org>:
I had this same exact problem while either upgrading or installing a package(s) and I simply removed it (which I was almost sure would break something anyway) and reran pacman and it seemed to work fine. Although I probably wouldnt recommend doing it because it could possibly affect one package differently from another.
On Wed, 2008-05-07 at 20:28 +0200, RedShift wrote:
Xavier wrote:
Lukáš Jirkovský wrote:
Hi I don't know if it's bug or feature, but it makes me crazy. It begun probably after some pacman upgrade. I'm using blowfish passwords with my archlinux, so my /lib/libcrypt.so.1 points to libxcrypt.so.1 instead of libcrypt-2.7.so from glibc. In my pacman.conf I have NoExtract = lib/libcrypt.so.1. But even though I've made this arrangements everytime when I run pacman -S some_interesting_package (it doesn't have to be glibc, eg libpng is enough) the link gets changed. Any suggestions?
From what I can tell, it's ldconfig who does this (try running it, it should overwrite your symlink). And pacman runs ldconfig when installing packages. Maybe someone can clarify further why ldconfig does this and if it's possible to prevent it.
ldconfig makes sure you are using the most recent version of a certain library and provides a cache for the runtime linker. See man 8 ldconfig.
Glenn
Lukáš Jirkovský wrote:
Thanks, so now I've to find some solutions to this. In the worst case I can make ldconfig wrapper.
man ldconfig : -l Library mode. Manually link individual libraries. Intended for use by experts only. I don't know what does that do and how to use it but it might be worth taking a look. But isn't the proper way to just remove libcrypt in the first place, to only have libxcrypt on the system (and then set up compatible symlinks)? Here are some instructions I found for lfs : http://www.mail-archive.com/hints@linuxfromscratch.org/msg00188.html You should be able to create your own glibc and libxcrypt packages based on that.
Yeah, but it glibc compiling much processor time. I've made small shell wrapper for ldconfig and it works. Maybe the best solution would be adding blowfish support to glibc's libcrypt itself. 2008/5/8 Xavier <shiningxc@gmail.com>:
Lukáš Jirkovský wrote:
Thanks, so now I've to find some solutions to this. In the worst case I can make ldconfig wrapper.
man ldconfig : -l Library mode. Manually link individual libraries. Intended for use by experts only.
I don't know what does that do and how to use it but it might be worth taking a look.
But isn't the proper way to just remove libcrypt in the first place, to only have libxcrypt on the system (and then set up compatible symlinks)? Here are some instructions I found for lfs : http://www.mail-archive.com/hints@linuxfromscratch.org/msg00188.html You should be able to create your own glibc and libxcrypt packages based on that.
On Thursday 08 May 2008 13:10:02 Lukáš Jirkovský wrote:
Yeah, but it glibc compiling much processor time. I've made small shell wrapper for ldconfig and it works. Maybe the best solution would be adding blowfish support to glibc's libcrypt itself.
Yet another external patch for glibc? Baaah.... However you may find interesting that glibc already supports sha256/sha512 password hashes. I remember having read that they intentionally prefered implementing those instead of blowfish. Ok I found it: http://people.redhat.com/drepper/sha-crypt.html Dimitris
participants (5)
-
Alec Hussey
-
Dimitrios Apostolou
-
Lukáš Jirkovský
-
RedShift
-
Xavier