Details
-
Bug
-
Resolution: Done
-
P2: Important
-
5.14.2
-
None
-
Fedora 31, LANG encoding UTF-8
-
-
19b6ae6637bde73ec508b6d1d29f3233e2c4e2d4 (qt/qtbase/dev) 973f0cee9e8134f2a647281aa36bc28d9255a1ee (qt/qtbase/5.15)
Description
When deploying a dynamically-linked application, the application might hang at startup, not showing any window but not quitting either.
After some investigation, I was able to identify that this happens when there are some non-ASCII characters in the path leading to the library (I deployed the application with a startup script that set LD_LIBRARY_PATH to point to the Qt libraries I provided).
Running the application in a debugger shows that there is an endless loop in the qlibraryinfo.cpp file, in the getRelocatablePrefix() function. Printing the path shows that there is an encoding problem : the path is an UTF-8 string that has been interpreted as a latin1 string (which can also be seen using strace).
Investigating the function, I found the four following lines in qlibraryinfo.cpp (lines 574 to 577 in my version, 5.14.2) :
Dl_info info; int result = dladdr(reinterpret_cast<void *>(&QLibraryInfo::isDebugBuild), &info); if (result > 0 && info.dli_fname) prefixPath = prefixFromQtCoreLibraryHelper(QString::fromLatin1(info.dli_fname));
What actually happens is that dladdr() fills the info struct with path encoded in UTF-8 (my console encoding), but then the prefixPath variable is set decoding it with QString::fromLatin1(), thus leading to an incorrect encoding.
I am not sure whether the behaviour of dladdr() is well-defined concerning the encoding of the strings, but on my system (Fedora 31), it uses the console encoding. I can confirm that by changing my console encoding (through the LANG variable) to iso88591, and running the app without any problem. If this behaviour is documented, I may suggest changing the QString::fromLatin1 to some system-dependent alternative (fromLocal8Bit() ?). I did not ask for a pull-request, because I am not sure this would fit any system.
I am aware that putting non-ASCII characters in path is a bad habit, and I personnaly never do that, but since some major Linux distributions come with default path names containing some of these (e.g. "Downloads" becomes "Téléchargements" in French, hence launching the app from a subfolder of this directory triggers this behaviour), I think it is worth opening an issue.
If you do not plan to fix this, it may be interesting to, at least, mention this on the documentation page about deploying applications (https://doc.qt.io/qt-5/linux-deployment.html).
Best regards,
MR
Attachments
Issue Links
- replaces
-
QTCREATORBUG-24240 After updating Qt Creator it is not visible after launch
-
- Closed
-
For Gerrit Dashboard: QTBUG-84272 | ||||||
---|---|---|---|---|---|---|
# | Subject | Branch | Project | Status | CR | V |
300901,3 | Fix relocated Qt to be found when its path has non-ASCII characters | dev | qt/qtbase | Status: MERGED | +2 | 0 |
301137,2 | Fix relocated Qt to be found when its path has non-ASCII characters | 5.15 | qt/qtbase | Status: MERGED | +2 | 0 |
301138,1 | Fix relocated Qt to be found when its path has non-ASCII characters | 5.14 | qt/qtbase | Status: ABANDONED | -1 | 0 |