How to remove 4 in QtCore4.dll

[jobrandt]

Hello,

if i compile Qt all generated dlls have the ending 4.dll.
Also if i use QTLIBINFIX the filename contains 4.
E.g. QTLIBINFIX=4.7.1 => QtCore4.7.14.dll
but it should be QtCore4.7.1.dll

How can i remove the 4?

I use windows. For linux it seems to be ok.

Thanks,
jobrandt

[squidge]

Is there a particular reason you want to do this? Typically QtCore4.DLL is backwards compatible on the binary level so you just make sure you have the latest and all programs will use that version.

[jobrandt]

I had a problem that a program runs with 4.5.1 but not with 4.7.0. But another program needs 4.7.0. It is possible to use different pathes. But it would be easier to have different names for the dlls.
There are other reasons to rename the dlls otherwise Qt hasn't implemented QTLIBINFIX.

[Timoteo]

How to allow your clients to freely update their Qt libs for use with your software? Do the right thing and fix your non-compliant software or link statically.

[squidge]

If the two programs requiring different versions of the DLL are in the same directory, then yes, you have a problem, but if they are in different directories, then you can just bundle the library with the application (or fix the application as stated above).

It is a known fault (QTBUG-7546), but with nothing happening since January, I wouldn't hold out for a fix anytime soon.

[wysota]

There is a trivial solution - rebuild Qt with a different suffix and link one of the applications against it. Then you can have two different versions of Qt in the same directory. I would opt for fixing your own code to work with 4.7 though.

[Timoteo]

Don't use the local library method. It can, and therefore will, break software. Just fix your software to work with all of Qt4 or link statically.

[Timoteo]

Ok, so I wanted to revisit this topic and elaborate on just how using a local copy of a lib can break software.

App X is deployed and has a local Qt library in the app directory (some random earlier version). All is fine. App Y is deployed and instead opts to use an installer that checks for Qt installed (and the version). It installs Qt 4.7 for the user and adds the brand new installation to the path. Everything seems fine.

What app Y does not know is that since app X is a command line utility, the user added X to the path too. When app Y starts to load, app X's directory is encountered on the path first. Yep, you guessed it. App X just broke app Y. The really bad part of it is that app Y was doing the right thing.

So change the suffix if you must keep local libs, but don't put vanilla libs in your app directory.

[wysota]

There is an alternative - make your app X a bat script that will set the PATH to its subdirectory containing the libraries and then call the proper executable. This won't cause the conflict mentioned.

[squidge]

What app Y does not know is that since app X is a command line utility, the user added X to the path too. When app Y starts to load, app X's directory is encountered on the path first. Yep, you guessed it. App X just broke app Y. The really bad part of it is that app Y was doing the right thing.

Not 100% the right thing though. You can never assume there will not be another DLL already installed on the system of an earlier version which may break your application (as in your case above). Therefore, you request the OS to search your local directory for dependencies first before going elsewhere. You can do this by simply creating an empty file as part of the installation. For example, if the application name was "AppY.exe", then you would create a file called "AppY.exe.local". Problem solved.

Doing it this way also means that you don't need to alter the path unless you want your application to be runnable from the command line.

[Timoteo]

In the case of app Y, you are relying on the system libs. Searching the local directory first doesn't make any sense in that case? Are you seriously suggesting that all deployed apps carry their own private Qt with them? The reason why (as you say) that one cannot assume that another version may be in the path that breaks the application, is because of this very behavior.

[squidge]

Yes, I suggest that, on Windows, all deployed apps carry their own version of Qt with them. We have enough DLL hell as it is because Windows simply can't handle libraries like Linux can, where you can have multiple versions of libraries in single directory (/lib) without any conflicts.

Windows is slowly moving to a slightly better system (you are able to specify the exact library version you want in your application manifest), but I don't see much take up on this technology yet, so rather than assuming everyone will be well managed, its much safer and easier for the end user to just duplicate things you can be 100% sure it will work after installation and not screw up anything else already installed.

Also, let us not forget that sometimes the library is compiled in GCC, sometimes MSVC++, sometimes another compiler - all incompatible with each each other, another thing that Linux doesn't have, where applications are typically all written using GCC.

After all, the main Qt library is what, 10 - 15MB? Assuming a typical user has 100 applications installed and they are all Qt-based, that's 1GB, and the typical drive size now is 500GB - 1TB. That's 0.1 - 0.2% of the drive space.