<snip>
>> Yes!  I'll pick an obvious example, KHTML.  I would like to replace the
broken KHTML engine with Webkit using Qt4.  Problem is, I can't link a
Qt4
>> library into a TDE library or program due to symbol conflicts.  Even if
you trick the compiler and linker, the program will crash at runtime
because the C++ runtime will not know which symbols (Qt3 or Qt4) to use
when function names and static members have the same name.
> But that is what the linker does. Isn't it? Looks at symbolic names and
puts addresses instead. Therefore you shouldn't have name
> conflicts at runtime. The crash you may encounter is because the linker
chosen wrong symbols to link together in one algorithm. But this have
obvious solution. Put the code you want to link with Qt4 in separate
module and link only with Qt4. I still don't understand how is renaming
better solves this. Could you please refer exact source file and
function?

Actually the linker creates a reference to a "mangled" symbol--see
http://en.wikipedia.org/wiki/Name_mangling#Name_mangling_in_C.2B.2B

Let's take a simple example, qWarning.  This becomes _Z8qWarningPKcz in
libqt-mt.so.3.3.8 (nm -D /usr/lib/libqt-mt.so | grep qWarning), and
_Z8qWarningPKcz in /usr/lib/libQtCore.so (nm -D /usr/lib/libQtCore.so |
grep qWarning).  If my program references Z8qWarningPKcz, which library
will the symbol resolver choose at runtime?  They are not binary
compatible with each other, and when the symbol resolver chooses the wrong
one at runtime (which it will do quite often) the entire program will
crash.

<snip>
> I suppose this could be done in more easy way without renaming.

Not really, see above. :-)

And if you want to work on a "pure" KDE 3.5.10 fork you have that right;
just be aware that you will hit a dead end far before TDE will. ;-)

Tim