On Linux, Qt creates the following files in the /tmp directory when using QSharedMemory:
qipc_sharedmemory_mysharedmem5ffa537fd8798875c98e190df289da7e047c05
qipc_systemsem_mysharedmem5ffa537fd8798875c98e190df289da7e047c05
I have come across a problem where two different versions of the same software use two different locations for these files, making them incompatible. The "newer" version instead creates these files in the /tmp/username/ directory. I can't seem to figure out what causes this. Is this location defined by Qt itself, and if so, did it change across versions? Or can it somehow be configured by the user, and if so, where and how?
I think you are experiencing a known Qt bug, as reported in the official bug tracker here: https://bugreports.qt.io/browse/QTBUG-60771
Briefly, there was a change between Qt 5.6 and Qt 5.8 in the way QSystemSemaphore (which is used by QSharedMemory) creates its keys. It was discovered that the method used to create the keys may cause collisions.
The incompatibility is documented in the changelog for Qt 5.9 here: https://code.qt.io/cgit/qt/qtbase.git/tree/dist/changes-5.9.0/?h=v5.9.0
[QTBUG-60771] Reverted a change that caused Qt 5.6 through 5.8 not to
connect to QSystemSemaphore and QSharedMemory created by running
applications using Qt earlier than 5.6. Unfortunately, this means that Qt
5.9 will not connect to 5.6-5.8.
You may experiment with the QSharedMemory::setNativeKey() method to force your own keys (and thus, file names in the /tmp directory). Although this means you should modify and recompile both versions of your software.
I'm afraid the "official" solution is to ensure you only use one version of Qt at the time.
Related
Our company ships 2 Qt applications, for now, using Qt5.6 but in some time there will be more (using newer Qt versions). So the problem is, how to make them work all together with different Qt versions? We won't be able to rebuild all Qt apps shipped before, especially if there will be plenty of them. I don't think it's a good idea to place all necessary Qt libraries with each app because the repository size will grow fast. And I think it's just not wise to have many Qt dlls of the same version at one place. As long as I know, .NET solve such problem of different versions with assemblies installer, but I don't think it can help me with Qt. So any ideas of how can I solve it would be highly appreciated. Thanks
UPD: The system is Windows
Actually an answer is quite straightforward, you can ship one Qt version (binaries) as long as they are binary compatible. With each release Qt announce binary compatibility or non-compatibility, so if for whatever reasons you need to switch to newer version and ship new applications with newer not compatible version you might want to ship a new Qt DLL chain.. This can be achived differently (depends on how you layout you install), for example you can have a common lib dir with sub directories based on Qt version which you will extend. (of course you will need appropriate PATHS set then running different applications) :
app\
app\app01
app\app02
...
lib\
lib\Qt5.6.1
lib\Qt5.7.0
etc, then you will have (for example) to wrap your exe files to .bat like:
run.bat
SET PATH=....\lib\Qt5.6.1\
app01.exe
etc..
it's all depends on your install layout and goals
I am looking for a way to create a minimal static build of Qt 5.1. By minimal, I mean a build with only the basic set of widget classes available (including 2D graphics acceleration through an OpenGL canvas/widget). I am aiming for a static build on Windows 7 32-bit using MinGW-builds GCC 4.8.1 as well as their bundle of MSYS and tools.
I have downloaded the entire source tree, and have met some problems with compiling due to the dependency of packages such as OpenSSL and ICU (the latest OpenSSL did not compile). I wanted to see, if I could avoid dependencies of these packages and, at the same time, achieve a minimal static build of Qt 5.1 so my final executable is not gigantic in size.
I took a look at this list:
http://download.qt-project.org/official_releases/qt/5.1/5.1.0/submodules/.
Q1: Which of these modules, do I need to select to have a basic Qt build without all the fancy stuff?
Q2: Are these modules interdependent on each other in some way (I assume they are all dependent on "qtbase")?
Q3: Do I use the names from that list, (for example: "qtxmlpatterns", "qtx11extras", "qtwebkit", etc.), to deselect them in the configuration of my Qt build?
It would also be nice, with an explanation of the various submodules of Qt 5? If someone could point to any links or docs with illuminating words on this subject, that would also be great.
I shared this same goal. I wanted to "minify" Qt, building only a small subset of the libraries/DLL(s) and omitting the rest.
I did succeed, at least on Mac OS X. I assume that this approach will work on other platforms, too.
I thought that the trick would be to find some kind of exclusion flags for the "configure" script, but that turned out not to be the case.
Here is what I did:
Download the source distribution (in my case, qt-everywhere-opensource-src-5.1.1). of course, extract it all.
Edit the following three "pro" files. these files are in a qt-specific format (but plain text). They are platform-independent project files that Qt (via qmake) uses to generate makefiles.
qtbase/src/src.pro
qtbase/src/plugins/plugins.pro
qtbase/examples/examples.pro
All the changes that I made to the "pro" files were deletions. I deleted references to: dbus, ipc, network, qtconcurrent, sql, xml, sqldrivers, qdbusxml2cpp, qdbuscpp2xml, src_dbus, src_concurrent, src_sql, src_network.
That last part may sound scary. It really wasn't.
The pro files contain a list of module names, plugin names, and directory names. It seemed fairly straightforward how to delete (for example) all SQL-related lines.
Step 3.
The usual configure/make/install. However, note the "module-qtbase" argument passed to make:
./configure -prefix ~/my_test_dir/
make -j2 module-qtbase
make -j2 module-qtbase-install_subtargets
Success. This built and installed only the essentials (QtCore, QtGui, QtOpenGL, QtWidgets) and skipped all the supporting dylibs like QtConcurrent, QtMultimedia, QtSql, and QtWebKit.
ICU can link statically, and you can customize it (see docs) to reduce size. By default the data is also large, I don't know how much data you need. You could include only enough data to run in one language.
Only part of an answer.
There's no need to disable Qt modules. Each application that uses Qt decides what modules it uses and links with. A basic console-only application may use the core module only. That's what you'd use when creating, say, a web service in Qt.
Recently we moved to QT 5.0.2 from QT4.8. Our project now needs more DLL files than the earlier. It requires qml, opengl, printer modules. However we did not use any of these modules in our application. The size of exe file increased due to additional DLLs.
QT-= qml opengl -> did not exclude this module from our application.
Are these additional DLLs are compulsory for Qt 5.0.2 ? Is there any way to come out from this? We need to exclude these dlls to reduce exe size.
Some of the modules you use may be dependent on those you don't, which means your project depends on them indirectly. For example, by default, some modules (QtWebKit, QtMultimedia) utilize ANGLE which uses OpenGL. You can try to trace those dependencies by using a program named Dependency Walker (available here). The Qt GUI has changed a lot since 4.8, and there are now separate modules for printing and other functions (see here).
Sources:
Qt 5 on Windows ANGLE and OpenGL
Qt 5 Deployment on Windows
By the way, someone has (had) a similar problem: http://www.qtcentre.org/archive/index.php/t-52102.html. (Unfortunately, there is no solution in that link.)
It turned out that this is actually a bug in Qt.
I'm developing a closed source application and to do so in accordance with the LGPL I have to dynamically link Qt's libraries to my application. Does Qt do this by default or do I have to take steps to do so? If that's the case how would I go about doing it?
Qt uses dynamic linking by default.
You'll notice this immediately during deployment to a non-developer machine, because your code will not run without the Qt libraries.
If your concern is the LGPL, just be careful when compiling Qt itself. Most LGPL violations with Qt are not because of static linking (since dynamic is the default), but for compiling Qt with non-default parameters.
LGPL is not just that the library must be provided along your binaries, but also that you specify how your users can build themselves the LGPL part. If you compile Qt yourself and do not use the pre-compiled binaries from the website, you must document that part of your build configuration in your release!
As soon as you get something running on your program, start preparing a release version for a non-developer environment without Qt installed. Your program should fail as soon as you delete the DLLs that you must copy along your program (or whatever format your OS uses).
It does it by default, statically linking seems to be quite involved judging by the many questions on the site regarding it.
I have multiple installations of Qt4 on my Windows XP SP2 machine and have installed Qt Creator 2.1 today. However, running the project (.pro) files spawns the oldest version of Qt Designer installed (the one installed in 2009 together with the rest of the framework).
Since
I would not like to remove any previous installations of Qt
and for some obscure reason even if I explicitly ask Windows Explorer to always use the version I need it does not
I would like to give up a bit and just sript the needed behaviour in a .bat file like:
e:\path\to\qtcreator.exe %1
This opens Qt Creator, but something seems to prevent it from treating the .pro file properly (in short, the project does not "open" as it should).
Qt documents have a page on the matter at Qt Creator: Using Command Line Options, but it seems to ignore the topic in question.
Since Qt (being as excellent framework as it is) is also known to have its quirks (like that of qmake), I wonder, may be there is an undocumented way to solve my problem?
(Another way to fix the thing would of course be to make the correct version of Qt Designer run, but frankly I'd prefer the "hard-wired" solution since the mechanisms provided by Qt itself are still a bit unreliable.)
The libraries and tools used for a particular project (and a configuration in it) is set in the Projects panel in Qt Creator:
http://doc.qt.io/qtcreator/creator-build-settings.html
Selecting the Qt version to use with a project should force it to run the Designer that's part of the version. If it doesn't, then you should report it as a bug.