Bug#442292: [xml/sgml-pkgs] Bug#442292:
On Mon, Sep 17, 2007 at 01:40:16AM -0400, Justin M. Keyes [EMAIL PROTECTED] wrote: I also have this problem. I don't have a libz.so.1 in /lib, but I have libz.so.1 in /usr/lib. This is the one that's supposed to exist. I can't run gnome, and I just get a root window in X. This problem is preventing me from updating some packages, because things like 'update-mime-database' and 'scrollkeeper-config' depend on libxml2.so.2. $ sudo apt-get dist-upgrade [snip] Removing sun-java6-jre ... update-mime-database: symbol lookup error: /usr/lib/libxml2.so.2: undefined symbol: gzopen64 Could this be caused by installing the ruby gems package manager by hand? Try something like strace -eopen -f update-mime-database 21 | grep libz.so and check where libz.so is taken from. If it's not taken in /usr/lib or /lib, then you're likely to have a broken LD_LIBRARY_PATH and/or a spurious libz.so somewhere else. Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#442292: [xml/sgml-pkgs] Bug#442292:
On 9/17/07, Mike Hommey [EMAIL PROTECTED] wrote: Try something like strace -eopen -f update-mime-database 21 | grep libz.so and check where libz.so is taken from. If it's not taken in /usr/lib or /lib, then you're likely to have a broken LD_LIBRARY_PATH and/or a spurious libz.so somewhere else. $ strace -eopen -f update-mime-database 21 | grep libz.so open(/usr/local/lib/libz.so.1, O_RDONLY) = 3 $ echo $LD_LIBRARY_PATH [empty] $ ls /usr/local/lib/libz.so.1 -l lrwxrwxrwx 1 root staff 13 2007-03-03 07:09 /usr/local/lib/libz.so.1 - libz.so.1.2.3 $ ls /usr/lib/libz.so.1 -l lrwxrwxrwx 1 root root 15 2007-07-16 13:28 /usr/lib/libz.so.1 - libz.so.1.2.3.3 There is also a directory called /usr/local/lib/site_ruby which holds the ruby gems stuff, so I'm guessing this issue is somehow related to installing ruby gems and *not* using apt (apt gems is broken, but I digress). So, it appears this issue may be my fault, but I'm clueless as to how to fix it. This link warns against setting $LD_LIBRARY_PATH: http://linuxmafia.com/faq/Admin/ld-lib-path.html Should I set the soft link at /usr/local/lib/libz.so.1 to point to /usr/lib/libz.so.1.2.3.3 (seems a tenuous solution)? How would installing ruby gems have caused gnome programs to prefer /usr/local/lib over /usr/lib ? How can I reverse that effect? Thanks, I really appreciate your time. -- Justin M. Keyes -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#442292: [xml/sgml-pkgs] Bug#442292:
On Mon, Sep 17, 2007 at 01:02:02PM -0400, Justin M. Keyes [EMAIL PROTECTED] wrote: On 9/17/07, Mike Hommey [EMAIL PROTECTED] wrote: Try something like strace -eopen -f update-mime-database 21 | grep libz.so and check where libz.so is taken from. If it's not taken in /usr/lib or /lib, then you're likely to have a broken LD_LIBRARY_PATH and/or a spurious libz.so somewhere else. $ strace -eopen -f update-mime-database 21 | grep libz.so open(/usr/local/lib/libz.so.1, O_RDONLY) = 3 $ echo $LD_LIBRARY_PATH [empty] $ ls /usr/local/lib/libz.so.1 -l lrwxrwxrwx 1 root staff 13 2007-03-03 07:09 /usr/local/lib/libz.so.1 - libz.so.1.2.3 $ ls /usr/lib/libz.so.1 -l lrwxrwxrwx 1 root root 15 2007-07-16 13:28 /usr/lib/libz.so.1 - libz.so.1.2.3.3 There is also a directory called /usr/local/lib/site_ruby which holds the ruby gems stuff, so I'm guessing this issue is somehow related to installing ruby gems and *not* using apt (apt gems is broken, but I digress). So, it appears this issue may be my fault, but I'm clueless as to how to fix it. This link warns against setting $LD_LIBRARY_PATH: http://linuxmafia.com/faq/Admin/ld-lib-path.html Should I set the soft link at /usr/local/lib/libz.so.1 to point to /usr/lib/libz.so.1.2.3.3 (seems a tenuous solution)? The simplest and most correct solution would be to remove all libz.so* files from /usr/local/lib. How would installing ruby gems have caused gnome programs to prefer /usr/local/lib over /usr/lib ? How can I reverse that effect? /etc/ld.so.conf.d/libc.conf is responsible for this. Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#442292: [xml/sgml-pkgs] Bug#442292:
On 9/17/07, Justin M. Keyes [EMAIL PROTECTED] wrote: On 9/17/07, Mike Hommey [EMAIL PROTECTED] wrote: Try something like strace -eopen -f update-mime-database 21 | grep libz.so and check where libz.so is taken from. If it's not taken in /usr/lib or /lib, then you're likely to have a broken LD_LIBRARY_PATH and/or a spurious libz.so somewhere else. $ strace -eopen -f update-mime-database 21 | grep libz.so open(/usr/local/lib/libz.so.1, O_RDONLY) = 3 [snip] Should I set the soft link at /usr/local/lib/libz.so.1 to point to /usr/lib/libz.so.1.2.3.3 (seems a tenuous solution)? I tried this. It works long enough to let me update some packages, but then 'apt-get dist-upgrade' sets it back at some point. Re-setting the link (again) to point to /usr/lib/libz.so.1.2.3.3 and running apt-get dist-upgrade multiple times allowed me to get my system up-to-date. But each time, apt-get seems to set /usr/local/lib/libz.so.1 to point to /usr/local/lib/libz.so.1.2.3. Of course, this is orthogonal to the problem, because as I understand it, programs should be looking in /usr/lib/ to begin with. -- Justin M. Keyes -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#442292: [xml/sgml-pkgs] Bug#442292:
On Mon, Sep 17, 2007 at 01:24:41PM -0400, Justin M. Keyes [EMAIL PROTECTED] wrote: On 9/17/07, Justin M. Keyes [EMAIL PROTECTED] wrote: On 9/17/07, Mike Hommey [EMAIL PROTECTED] wrote: Try something like strace -eopen -f update-mime-database 21 | grep libz.so and check where libz.so is taken from. If it's not taken in /usr/lib or /lib, then you're likely to have a broken LD_LIBRARY_PATH and/or a spurious libz.so somewhere else. $ strace -eopen -f update-mime-database 21 | grep libz.so open(/usr/local/lib/libz.so.1, O_RDONLY) = 3 [snip] Should I set the soft link at /usr/local/lib/libz.so.1 to point to /usr/lib/libz.so.1.2.3.3 (seems a tenuous solution)? I tried this. It works long enough to let me update some packages, but then 'apt-get dist-upgrade' sets it back at some point. Re-setting the link (again) to point to /usr/lib/libz.so.1.2.3.3 and running apt-get dist-upgrade multiple times allowed me to get my system up-to-date. But each time, apt-get seems to set /usr/local/lib/libz.so.1 to point to /usr/local/lib/libz.so.1.2.3. Then you should try something like dpkg -S /usr/local/lib/libz.so.1. Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#442292: [xml/sgml-pkgs] Bug#442292:
On 9/17/07, Mike Hommey [EMAIL PROTECTED] wrote: On Mon, Sep 17, 2007 at 01:02:02PM -0400, Justin M. Keyes [EMAIL PROTECTED] wrote: On 9/17/07, Mike Hommey [EMAIL PROTECTED] wrote: Try something like strace -eopen -f update-mime-database 21 | grep libz.so and check where libz.so is taken from. If it's not taken in /usr/lib or /lib, then you're likely to have a broken LD_LIBRARY_PATH and/or a spurious libz.so somewhere else. $ strace -eopen -f update-mime-database 21 | grep libz.so open(/usr/local/lib/libz.so.1, O_RDONLY) = 3 $ echo $LD_LIBRARY_PATH [empty] $ ls /usr/local/lib/libz.so.1 -l lrwxrwxrwx 1 root staff 13 2007-03-03 07:09 /usr/local/lib/libz.so.1 - libz.so.1.2.3 $ ls /usr/lib/libz.so.1 -l lrwxrwxrwx 1 root root 15 2007-07-16 13:28 /usr/lib/libz.so.1 - libz.so.1.2.3.3 There is also a directory called /usr/local/lib/site_ruby which holds the ruby gems stuff, so I'm guessing this issue is somehow related to installing ruby gems and *not* using apt (apt gems is broken, but I digress). So, it appears this issue may be my fault, but I'm clueless as to how to fix it. This link warns against setting $LD_LIBRARY_PATH: http://linuxmafia.com/faq/Admin/ld-lib-path.html Should I set the soft link at /usr/local/lib/libz.so.1 to point to /usr/lib/libz.so.1.2.3.3 (seems a tenuous solution)? The simplest and most correct solution would be to remove all libz.so* files from /usr/local/lib. That suggestion is supported by the discussion at bug #440394: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=440394 How would installing ruby gems have caused gnome programs to prefer /usr/local/lib over /usr/lib ? How can I reverse that effect? /etc/ld.so.conf.d/libc.conf is responsible for this. So the problem is that some outdated or incompatible lib(s) was installed in /usr/local/lib by a (e.g.) make install that I did somewhere along the line. And based on bug #440394, it is correct behavior to search /usr/local/lib before /usr/lib. Mike, thanks for your help. -- Justin M. Keyes -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#442292: [xml/sgml-pkgs] Bug#442292: symbol lookup error: /usr/lib/libxml2.so.2: undefined symbol: gzopen64
On Fri, Sep 14, 2007 at 03:41:30PM -0300, Mauro Meloni [EMAIL PROTECTED] wrote: Subject: symbol lookup error: /usr/lib/libxml2.so.2: undefined symbol: gzopen64 Package: libxml2 Version: 2.6.30.dfsg-2 Severity: grave Justification: renders package unusable Whenever I try to use synaptic, eog, or another Gnome app, I get the following message: symbol lookup error: /usr/lib/libxml2.so.2: undefined symbol: gzopen64 Let me bet... you have a spurious libz.so.1 in /lib. Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
