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.

[Timoteo]

I can agree with you that it is easier (for us, and most likely for the user). What I am having trouble with is stomaching the "right" part of it. I think that it is simply knowing that if everyone played nice, then this wouldn't be necessary.

[squidge]

If libraries worked on Windows like they do under Linux, then yes, it wouldn't be necessary, but they don't, and unless we make some consequences, we all end up in DLL hell, kinda like the newbies who deploy their first application and get the weird error messages because they copied QtCore4 from the QtCreator directory rather than the lib directory (Same version, different compiler)

Remember when everyone was recommended to copy library files directly into C:\Windows\System on Windows95?

[wysota]

Is there some kind of even remote equivalent of rpath on Windows? Does the manifest perform such a task?

[squidge]

The only real alternative is the SetDllDirectory() function which was introduced in XP SP1, but this of course requires your application to be running before you load any libraries, and if there is a library in the current directory with the same name as the one you are loading, the directory given to this function is ignored, plus if the library can not be found in the current directory or the directory specified by this function, then it reverts to standard search order.

To confirm the correct set of DLLs are loaded by using a manifest, you would first turn your DLLs in an assembly, by creating a file like so:

<assembly manifestVersion="1.0">
  <assemblyIdentity type="Win32" name="mydlls.assembly" version="1.0.0.0" processorArchitecture="x86"/>
 <file name="QtCore4.dll" hashalg="SHA1"/>
 <file name="QtGUI4.dll" hashalg="SHA1"/>
</assembly>

<assembly manifestVersion="1.0">
  <assemblyIdentity type="Win32" name="mydlls.assembly" version="1.0.0.0" processorArchitecture="x86"/>
 <file name="QtCore4.dll" hashalg="SHA1"/>
 <file name="QtGUI4.dll" hashalg="SHA1"/>
</assembly>

To copy to clipboard, switch view to plain text mode 

Your application would then have a manifest embedded within it (or as a seperate .manifest file) which stated that it required "mydlls.assembly" of version "1.0.0.0" and processorArchitecture "x86".

You can then go further if you wished and cryptographically sign the complete assembly package to ensure the correct DLLs are always used with your application (hence the "hashalg" value which may be optional - there is also a publickeytoken value).

For Windows 7, you can also do probing paths, but lets not go there yet, considering how new the OS is.

[wysota]

To confirm the correct set of DLLs are loaded by using a manifest, you would first turn your DLLs in an assembly, by creating a file like so:

<assembly manifestVersion="1.0">
  <assemblyIdentity type="Win32" name="mydlls.assembly" version="1.0.0.0" processorArchitecture="x86"/>
 <file name="QtCore4.dll" hashalg="SHA1"/>
 <file name="QtGUI4.dll" hashalg="SHA1"/>
</assembly>

<assembly manifestVersion="1.0">
  <assemblyIdentity type="Win32" name="mydlls.assembly" version="1.0.0.0" processorArchitecture="x86"/>
 <file name="QtCore4.dll" hashalg="SHA1"/>
 <file name="QtGUI4.dll" hashalg="SHA1"/>
</assembly>

To copy to clipboard, switch view to plain text mode 

Your application would then have a manifest embedded within it (or as a seperate .manifest file) which stated that it required "mydlls.assembly" of version "1.0.0.0" and processorArchitecture "x86".

You can then go further if you wished and cryptographically sign the complete assembly package to ensure the correct DLLs are always used with your application (hence the "hashalg" value which may be optional - there is also a publickeytoken value).

So it will keep looking for the right libraries until it finds them or if it finds a matching library that has a different hash or is in different version it will say "sorry, dude, bailing out"?

[squidge]

Not something I've messed with much to be honest. Generally, the appropriate DLLs are in the same folder as the xml file, but you can specify different directories in the xml file as to where to find the DLLs (for example, a company may place some of there DLLs in a directory "Common files" or similar).

It would be interesting to see what happened if the DLL in the directory with the XML was an older version, where the proper version was much further down the search path. If the assembly was hashed it would probably reject the former, but it's not something I've messed with much.