Dallas,
Some clarifications first. libqtc.so.1 is a library that BCompare uses not something that we have written ourselves. We include it since must distributions do not have it.
When you do 'ldd' on an object the resulting paths are not hardcoded in the object but where the dynamic linker was able to find the needed libraries. So when ldd says that libqtc.so.1 is using /usr/lib/libqt-mt.so, this is not a hardcoded path in libqtc.so.1 but the first place that the linker found a copy of libqt-mt.so in your filesystem.
Libraries can reside anywhere inside your filesystem - the key is getting the linker to find them. There are standard directories that the linker looks in /lib, /usr/lib, /usr/local/lib, etc. You can add to the search paths with the environment variable LD_LIBRARY_PATH. This is what the bcomp script does. It sets LD_LIBRARY_PATH to include the directory where libqtc.so.1 resides so that the linker can find libqtc.so.1 when it runs BCompare. This is why you cannot run BCompare straight out - LD_LIBRARY_PATH is not set to include the location of libqtc.so.1 (you can manually set LD_LIBRARY_PATH and call ./BCompare - directly though you would loose some other functionality that the bcomp script provides). (google or manpage ldconfig, ldd, ld, ld.conf).
I believe that this is also the reason why libqtc.so.1 was not found when you did 'ldd BCompare' i.e. LD_LIBRARY_PATH was not set to include the location of libqtc.so.1 and therefore the linker could not find it.
So back to fixing your problem.
The library that you created does appear to have the correct symbols in it. Though we could do one more grep to make sure that the full symbol is there. So
'grep _ZNK13QWindowsStyle9classNameEv libqt-mt.so.3'
and verify that there is a match.
If there is a match it should just be a matter of getting that library in the correct location that the linker can find it first before it finds the old libqt-mt.so.3.
If it were my machine I would create a temp directory in my home directory and move all the old Qt library stuff there. Since this directory would not be in the linker search path then it should never find that old library. The test would be that if you try to run bcomp then you should see an error message about libqt-mt.so.3 not found (assuming that the new libqt-mt.so.3 is not sitting in a directory known by the linker).
It would actually be useful to make sure that the new libqt-mt.so.1 is not in a standard searchable directory. If it is not then you can keep removing any libqt-mt.so.1's that are found when you ldd libqtc.so.1 until none are found. This way you can guarantee that it is using the one that you want it to use. Sine you have already run a 'find' on libqt-mt.so* then there are probably on the old one and the one you just created. However... it wouldn't hurt to verify that.
I would then go ahead and copy the new libqt-mt.so.3 straight into /usr/lib (no symbolic links - the symbolic links are a convenience to allow you to easily change the link to different/new versions of the library). And then try running bcomp.
David
Some clarifications first. libqtc.so.1 is a library that BCompare uses not something that we have written ourselves. We include it since must distributions do not have it.
When you do 'ldd' on an object the resulting paths are not hardcoded in the object but where the dynamic linker was able to find the needed libraries. So when ldd says that libqtc.so.1 is using /usr/lib/libqt-mt.so, this is not a hardcoded path in libqtc.so.1 but the first place that the linker found a copy of libqt-mt.so in your filesystem.
Libraries can reside anywhere inside your filesystem - the key is getting the linker to find them. There are standard directories that the linker looks in /lib, /usr/lib, /usr/local/lib, etc. You can add to the search paths with the environment variable LD_LIBRARY_PATH. This is what the bcomp script does. It sets LD_LIBRARY_PATH to include the directory where libqtc.so.1 resides so that the linker can find libqtc.so.1 when it runs BCompare. This is why you cannot run BCompare straight out - LD_LIBRARY_PATH is not set to include the location of libqtc.so.1 (you can manually set LD_LIBRARY_PATH and call ./BCompare - directly though you would loose some other functionality that the bcomp script provides). (google or manpage ldconfig, ldd, ld, ld.conf).
I believe that this is also the reason why libqtc.so.1 was not found when you did 'ldd BCompare' i.e. LD_LIBRARY_PATH was not set to include the location of libqtc.so.1 and therefore the linker could not find it.
So back to fixing your problem.
The library that you created does appear to have the correct symbols in it. Though we could do one more grep to make sure that the full symbol is there. So
'grep _ZNK13QWindowsStyle9classNameEv libqt-mt.so.3'
and verify that there is a match.
If there is a match it should just be a matter of getting that library in the correct location that the linker can find it first before it finds the old libqt-mt.so.3.
If it were my machine I would create a temp directory in my home directory and move all the old Qt library stuff there. Since this directory would not be in the linker search path then it should never find that old library. The test would be that if you try to run bcomp then you should see an error message about libqt-mt.so.3 not found (assuming that the new libqt-mt.so.3 is not sitting in a directory known by the linker).
It would actually be useful to make sure that the new libqt-mt.so.1 is not in a standard searchable directory. If it is not then you can keep removing any libqt-mt.so.1's that are found when you ldd libqtc.so.1 until none are found. This way you can guarantee that it is using the one that you want it to use. Sine you have already run a 'find' on libqt-mt.so* then there are probably on the old one and the one you just created. However... it wouldn't hurt to verify that.
I would then go ahead and copy the new libqt-mt.so.3 straight into /usr/lib (no symbolic links - the symbolic links are a convenience to allow you to easily change the link to different/new versions of the library). And then try running bcomp.
David
Comment