From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030701 Description of problem: RH9 is missing two library links that were present in previous versions: /usr/lib/libtk.so.0 /usr/lib/libtcl.so.0 This means that programs that use tcl/tk that were built on a previous version break in RH9. Simply creating a link from /usr/lib/libtcl.so.0 to /usr/lib/libtcl.so or /usr/lib/libtcl8.3.so solves the problem. Version-Release number of selected component (if applicable): tk-8.3.5-88 How reproducible: Always Steps to Reproduce: 1. n/a Actual Results: Programs break between RH8.0 and RH9. Expected Results: They just work. Additional info:
Yes, I am afraid this is intentional. The so names in RHL 8.0 and earlier were non-standard (ad-hoc). I decided when updating tcltk for RHL 9 that following the so naming conventions of upstream is the right thing to do.
As I'm sure you are aware this very undesireable. Here at JHU we have a large collection of systems that use a shared /usr/local. As we update our systems incrementally we have both RH8.0 and RH9 in production. Lots of broken software... That said, it sounds like you made the right decision to use the standard naming. Is there some kind of meta-bug for similar backward compatibility and API/ABI stability issues? These are very important for many people.
*** Bug 104579 has been marked as a duplicate of this bug. ***
As noted in bug 104579 there is backwards compatibility however: On RHL 8.0 and earlier there is a symlink lib{tcl,tk}8.3.so -> lib{tcl,tk}.so.0, so programs linked against tcltk on RHL9 should run ok on 8.0 all other things being equal. I'm not aware of a better place to report API/ABI issues.