Hide Forgot
Description of problem: aMSN 0.98.4-4.fc16(64-bit) misses TkCximage Version-Release number of selected component (if applicable): 0.98.4-4.fc16(64-bit) How reproducible: Install 0.98.4-4.fc16(64-bit) Steps to Reproduce: 1.Install 0.98.4-4.fc16(64-bit) 2.Start aMSN 3. Actual results: aMSN won't start Expected results: aMSN start-up Additional info: There's a problem loading a module of aMSN(TKCxImage): couldn't load a file "utils/TkCximage/TKCximage.so":libgupnp-1.0.so.3: cannot open shared object file: No such file or directory
Hi, do you still have still problem?
(In reply to comment #1) > Hi, do you still have still problem? Confirmed. Problem persists.
Looks like something weird is going on in your setup, you should not have a utils/TkCximage/TKCximage.so. Did you compile amsn from source yourself?
(In reply to comment #3) > Looks like something weird is going on in your setup, you should not have a > utils/TkCximage/TKCximage.so. Did you compile amsn from source yourself? Good question. I remember having deleted amsn and amsn plugins. Then, somewhere else I downloaded a previous version of amsn for fedora which was said to work fine. Since that version had issues, too. I deleted those packages and re installed form fedora repository amsn and amsn plugins. How would I delete all and give it a fresh start?
Hi, you can type: locate utils/TkCximage/TKCximage.so If it gives you any hits, you can remove (or move, or rename) that folder to make sure it isn't used. Als you can try: rpm -V amsn
(In reply to comment #5) > Hi, > > you can type: > locate utils/TkCximage/TKCximage.so > > If it gives you any hits, you can remove (or move, or rename) that folder to > make sure it isn't used. > > Als you can try: > rpm -V amsn Did that. Both return no results. Might be because "cannot open shared object file: No such file or directory". What is not there, cannot be found. Right?
Strange thing is the reference to libgupnp-1.0.so.3, Amsn should require libgupnp-1.0.so.4, not .3. I still do think something is wrong in your setup. What does `ldd /usr/lib64/tcl8.5/gupnp/gupnp.so` say? and `locate gupnp.so`?
(In reply to comment #7) > Strange thing is the reference to libgupnp-1.0.so.3, Amsn should require > libgupnp-1.0.so.4, not .3. I still do think something is wrong in your setup. > What does `ldd /usr/lib64/tcl8.5/gupnp/gupnp.so` say? > and `locate gupnp.so`? # ldd /usr/lib64/tcl8.5/gupnp/gupnp.so linux-vdso.so.1 => (0x00007fff79de2000) libpng12.so.0 => /usr/lib64/libpng12.so.0 (0x00007f3a54436000) libz.so.1 => /lib64/libz.so.1 (0x00007f3a5421f000) libm.so.6 => /lib64/libm.so.6 (0x00007f3a53f9a000) libjpeg.so.62 => /usr/lib64/libjpeg.so.62 (0x00007f3a53d4e000) libv4l2.so.0 => /usr/lib64/libv4l2.so.0 (0x00007f3a53b42000) libgupnp-igd-1.0.so.3 => /usr/lib64/libgupnp-igd-1.0.so.3 (0x00007f3a5393a000) libgupnp-1.0.so.4 => /usr/lib64/libgupnp-1.0.so.4 (0x00007f3a53715000) libgssdp-1.0.so.3 => /usr/lib64/libgssdp-1.0.so.3 (0x00007f3a53507000) libxml2.so.2 => /usr/lib64/libxml2.so.2 (0x00007f3a531ab000) libsoup-2.4.so.1 => /usr/lib64/libsoup-2.4.so.1 (0x00007f3a52f43000) libgio-2.0.so.0 => /lib64/libgio-2.0.so.0 (0x00007f3a52c02000) libgobject-2.0.so.0 => /lib64/libgobject-2.0.so.0 (0x00007f3a529b2000) libgmodule-2.0.so.0 => /lib64/libgmodule-2.0.so.0 (0x00007f3a527ae000) libgthread-2.0.so.0 => /lib64/libgthread-2.0.so.0 (0x00007f3a525a9000) librt.so.1 => /lib64/librt.so.1 (0x00007f3a523a0000) libglib-2.0.so.0 => /lib64/libglib-2.0.so.0 (0x00007f3a52080000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f3a51e64000) libc.so.6 => /lib64/libc.so.6 (0x00007f3a51aab000) libv4lconvert.so.0 => /usr/lib64/libv4lconvert.so.0 (0x00007f3a51832000) libuuid.so.1 => /lib64/libuuid.so.1 (0x00007f3a5162d000) libdl.so.2 => /lib64/libdl.so.2 (0x00007f3a51428000) libffi.so.5 => /usr/lib64/libffi.so.5 (0x00007f3a51220000) libselinux.so.1 => /lib64/libselinux.so.1 (0x00007f3a50fff000) libresolv.so.2 => /lib64/libresolv.so.2 (0x00007f3a50de3000) /lib64/ld-linux-x86-64.so.2 (0x0000003625400000) # locate gupnp.so /home/dfrster/amsn/utils/gupnp/gupnp.so /usr/lib64/tcl8.5/gupnp/gupnp.so /usr/share/amsn/utils/gupnp/gupnp.so
/usr/share/amsn/utils/gupnp/gupnp.so is not from the amsn package, I guess you did a make install at some point in the past yourself. If you remove it I suspect things will work again.
(In reply to comment #9) > /usr/share/amsn/utils/gupnp/gupnp.so is not from the amsn package, I guess you > did a make install at some point in the past yourself. If you remove it I > suspect things will work again. Deleted gupnp.so . Problem persists. Message reads: "There's a problem loading a module of aMSN (TkCxImage) : couldn't load file "utils/TkCximage/TkCximage.so":libgupnp-1.0.so.3: cannot open shared object file: No such file or directory" Next message: "Loading TkCximage failed. This module is needed to run aMSN. Please compile aMSN first, instructions on how to compile are located in the file INSTALL"
I am still convinced it has to do with your own local install. Maybe try to remove /home/dfrster/amsn/utils/gupnp/gupnp.so. Else cd /home/dfrster/amsn && sudo make uninstall
(In reply to comment #11) > I am still convinced it has to do with your own local install. Maybe try to > remove /home/dfrster/amsn/utils/gupnp/gupnp.so. Else cd /home/dfrster/amsn && > sudo make uninstall Thank you. You were right. I did that and re-installed amsn from fedora repository. amsn works now for chat but webcam still does not work which was the reason in the first place to try compiling an earlier version of amsn which failed. I still wonder why after having installed amsn via fedora repository, webcam remains an issue.
This message is a reminder that Fedora 16 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 16. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '16'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 16's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 16 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged to click on "Clone This Bug" and open it against that version of Fedora. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 16 changed to end-of-life (EOL) status on 2013-02-12. Fedora 16 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.