[kde-solaris] CSWqt libqt-mt (v.3.3.3) conflicts with KDE-gcc libqt-mt (v.3.3.4)

[BobC]

Hi KDE users-

First off, I'd like to thank the folks that compiled KDE on Solaris.
It's a great desktop on Solaris IMHO, and installation from the
blastwave site makes it even better!

But, I experienced a problem I thought I'd let folks know about (with
a workaround).

I installed VLC from blastwave after I installed KDE from blastwave
(and unfortunately walked away from my box for a week on a business
trip). When I got back and logged in, kded would die and dump core
every time. After spending many mornings and nights, I finally
discovered what was happening.

On startup, kded was using /opt/csw/lib/libqt-mt.so.3 from CSWqt,
instead of /opt/csw/kde-gcc/lib/libqt-mt.so.3. The
/opt/csw/lib/libqt-mt.so* libs are symbollically linked to
/opt/csw/lib/libqt-mt.so.3.3.3 while KDE needed libqt-mt.so.3.3.4 from
/opt/csw/kde-gcc/lib.

So it appears there *could* be a package conflict between kde-gcc and
anything else that needs libraries from CSWqt (that live in
/opt/csw/lib).

To fix it, I created appropriate symbolic llinks from the libqt-mt
libraries in /opt/csw/lib to the libraries in /opt/csw/kde-gcc/lib.
But, this now breaks my package database and the pkging repository
(amoung other things), and I have to *assume* libqt-mt.so.3.3.3 is
fully backward compatible with libqt-mt.so.3.3.4 (which might not be a
safe assumption), but it appears most of my other apps work from what
I can tell.

So my question is, how else could I fix this without breaking my
packaging, kde-gcc or the other CSW apps that depend on CSWqt out of
/opt/csw/lib (knowing there are apps that may need both versions of
qt-mt) ?

I've thought about submitting this as a bug/package conflict on
blastwave's bug tracking system if that would help.... anyway, any
other suggestions about how to more gracefully fix "versioned dynamic
linking" without recompiling or breaking other apps would be greatly
appreciated.

Thanks,
Bob