Printable View
Anyone out there know how to build the Qt libraries with custom names? For example, FooQtCore4.dll, FooQtGui4.dll, et. al.? Maybe I just can't parse the documentation for configure correctly in my overtaxed brain?
Reason I'm asking is that some customers of ours have run into compatibility problems. We shipped 4.2.3, they unwittingly tried to use a 3rd-party lib that requires 4.3 and ... well, you know the drill. :D
You'd have to change the sources of qmake, sources of the libraries and qmakespecs. Maybe it is simpler to make a local library install (deploy in the same directory where the executable resides) or even a static build?
Define 'simpler'. ;-)
We currently ship the Qt libraries 'side-by-side' and have already encountered a compatibility problem in the field. (Only 2 months after release.)
It turns out at QtGui4.dll versions 4.1.0.0 - 4.2.0.0 exported a couple of QVector::append functions. But, starting in Qt 4.2.1, these exports disappeared from QtGui4.dll.
Our application is actually a programming language / development environment, and it has hooks to the 'standard' source code control API in Windows. This lets our customers use their favorite SCC tools with our development environment. We recently learned that one of these (Surround SCM from Seapine) was built w/ Qt 4.1.0.0. Unfortunately, they can't use it with our app because we shipped Qt 4.2.3, which doesn't have those QVector exports. Unless, of course, we have them downgrade the Qt we use to be 4.2.0. In this particular customer's case, it'll work, because they don't need other features of our product that *do* require 4.2.3.
I know for our future releases (which I'm working on), we will need to build Qt slightly differently than the shipping binaries from Trolltech.
So, it's the classic DLL Hell problem. If our QtGui4.dll, for example, isn't what some random 3rd party DLL used by our customers is expecting, random 3rd party DLL gets in trouble, through no fault of its own. It gets our custom QtGui4.dll whether it wants it or not, given the way Windows loads DLLs.
Hence, the desire to 'namespace' our version of Qt by having all the DLLs with unique names. I was hoping to be able to do this via some clever build rule, and not a lot of work. Unfortunately, that isn't looking good. qt.conf isn't going to solve this problem as far as I can tell.
On top of all that, within our company, we standardize on our custom-built version of Qt, and develop support DLLs / Frameworks / .sos that add into our application software -- so just using static libs isn't the right approach, either.
I suppose we could build static Qt libraries and then build our own DLLs that export interfaces. Again, being the lazy type, I was hoping to avoid this effort and just pass some magic argument to the Qt build. Silly me! :-P
You won't be able to link against two different versions of Qt libraries, because of symbol name clashes anyway, so I don't think changing the name will improve anything.
Not an issue. Everything we'd ship only links against our own custom version of the libraries. The loader would expect, say. FOOQt*.dll and never look for the standard ones.
Libraries built by others would continue to look for Qt*.dll.
I suspect that the Perforce SCM does something similar... It looks like they rolled the parts of Qt they need into a DLL of their own fashioning... which is what we may end up needing to do.
Have you tried simply renaming the libraries and adjusting the specs so that they point to new names? If you use GCC/MinGW you can also force looking for libraries in a particular directory. Or you can adjust the library search path environment variable before running the application.
Unfortunately, you actually need to rebuild all of the Qt DLLs (other than QtCore), since all the other Qt shared libraries have linkages back to QtCore, some to QtGui, and one to QtXml. So, to get full 'namespacing' you need to rebuild everything so the .lib files have the properly udpate linker info.
I've made all the necessary adjustments, and still need to do some testing to see what happens when a 'regular' Qt DLL loads up next to these 'custom' ones. All of *our* features that use *our* builds work just fine. It's the unknown 3rd party beasties that customers can pull into our app that we need to do some further testing with.
Fundamentally, at least in Windows, the Qt versioning is fubar. I can understand forward compatibility problems, i.e. 4.3 has exports that 4.2 does not, for example... but the loss of exports (4.1 has some that 4.2.1 does not) is really bad. IMO, exports from libraries should not be allowed to change w/o *properly* versioning the library. :) That helps avoid these kinds of problems, at the expense of more files on the system.
I don't know if the Qt .so files are fully versioned (e.g. QtGui4.3.1.so or however the typical Unix sytnax goes), but in Windows, at least, the 'whole number' approach for Qt4 presents a serious compatibility problem for an application such as ours.
Are you sure that some exports are actually missing? Trolltech is very sensitive about it to provide backward compatibility... Maybe one of the libraries is a custom build that simply doesn't have some of the features of the other one?
Yes, I'm sure about the break in compatibility, and have gotten confirmation from Trolltech that this happened. They apparently didn't realize this!? Honestly, I'm quite surprised that they don't run a check on their exports e.g. something as simple as diffing results from dumpbin when readying a new version).
Between 4.1 and 4.2, for example, some exports in QtGui disappeared (a couple of what may have been inadvertant QVector::append exports, for example).
Clearly, 'future' exports can't be maintained, e.g. 4.3 stuff won't be in 4.2. But losing exports when moving to newer versions is bad, bad bad. I did the check using the binaries that Trolltech ships, so this problem is not due to special builds and whatnot.