Description of problem: ds9 fails to load in 64-bit platforms, at "package require BLT" in "/usr/share/ds9/src/ds9.tcl" (full output attached). Version-Release number of selected component (if applicable): 5.1-1.fc8 How reproducible: always Steps to Reproduce: 1. Install ds9 on 64-bit Fedora 8 2. Try to run ds9. Actual results: script fails; see above Expected results: ds9 loads properly Additional info: This can be fixed by adding setting TCLLIBPATH=/usr/lib64 before running ds9, which suggests it's a problem with tcl not having 64-bit packages available in its package path by default, but I don't know about tcl to know the proper way to fix this.
Created attachment 299262 [details] error message
I can't reproduce the problem. In my x86_64 machine I have made: # yum remove blt (it removes ds9 also) and then # yum install ds9 (it installs blt also) And then ds9 works properly. So please, could you give the ouput of this command: rpm -q --qf '%{NAME}-%{VERSION}.%{RELEASE}.%{ARCH}\n'
Created attachment 299419 [details] output of "rpm -qa ..." prior to the tinkering described in my comment
I tried your remove/install pair, and noticed that prior to remove, I had both x86_64 and i386 versions of blt; after reinstall, I had only x86_64, and the the error switched to libtclxpa.so. I then removed xpa-tcl (both arches) and reinstalled ds9; error message switched to libtkimg1.3.so. One more pass (removing tkimg, reinstalling ds9) fixed the problem completely. I then reinstalled the 32-versions of these packages, and the problem reappeared. In short, with only x86_64 libraries, ds9 works fine. With any of the 32-bit libraries installed, it does not. In case you're still curious, I have attached the output of rpm -qa prior to doing the above.
Maybe this is a multilib problem? http://fedoraproject.org/wiki/PackagingDrafts/MultilibTricks
Ok, now I can reproduce the bug. I have installed ds9.x86_64 and the i386 version of blt. When the i386 version of blt is installed, the i386 is loaded instead of the x86_64. This problem is not related with ds9, but with the way tcl 8.4 loads packages. If you have only tcl.x86_64 and blt.x86_64, this works: $ tclsh % package require BLT 2.4 But if you install also blt.i386 you get $ tclsh % package require BLT couldn't load file "/usr/lib/blt2.4/libBLTlite24.so": /usr/lib/blt2.4/libBLTlite24.so: wrong ELF class: ELFCLASS32 So let me search if there's a tcl bug like this already reported. As a temporary workaround install only the x86_64 versions of the dependencies of ds9.
I'm CCing Michael Thomas, the maintainer of blt. Michael, do you think this is a bug of tcl or a bug of blt (and tkimg and xpa-tcl)?
This is a bug in Tcl that has been fixed in Fedora 9. The problem is that tcl.x86_64 includes both /usr/lib/ and /usr/lib64/ in the list of directories that it uses to find packages ($auto_path). If blt.i386 is installed, then it is found first and used, even though blt.x86_64 is also installed. What I don't understand is why 'yum install blt' will install both the i386 and x86_64 packages.
I'm going to reassign this bug to tcl
I didn't find any ds9 in older repositories (F-8,...). That's strange. In the F-9 repository is only ds9.x86_64 release, so I'd like to close it as nextrelease.