ignite odbc SQLSTATE [01000] error How do I fix it? - odbc

I've installed ignite 2.7 , nginx, php7.0-fpm.
I also installed unixodbc, unixodbc-dev, libtool, automake, libssl-dev, and m4.
The odbc installation looked at the official homepage and followed up, but there was a problem.
cat odbc.ini // odbcinst.ini // .odbc.ini (all same)
[Apache Ignite]
Description=Apache Ignite
DSN=Apache Ignite
Driver=/usr/local/lib/libignite-odbc.so
Setup=/usr/local/lib/libignite-odbc.so
DriverODBCVer=03.00
FileUsage=0
UsageCount=1
tail /etc/profile
export JAVA_HOME=/usr/lib/jvm/java-8-openjdk-amd64
export LD_LIBRARY_PATH=/usr/local/lib/
ldd /usr/local/lib/libignite-odbc.so
linux-vdso.so.1 => (0x00007ffef07c0000)
libignite-binary-2.7.0.33575.so.0 => /usr/local/lib/libignite-binary-2.7.0.33575.so.0 (0x00007fd8b8d4d000)
libodbcinst.so.2 => /usr/lib/x86_64-linux-gnu/libodbcinst.so.2 (0x00007fd8b8b3b000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007fd8b87b9000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fd8b83ef000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fd8b81d9000)
libignite-common-2.7.0.33575.so.0 => /usr/local/lib/libignite-common-2.7.0.33575.so.0 (0x00007fd8b7fc2000)
libltdl.so.7 => /usr/lib/x86_64-linux-gnu/libltdl.so.7 (0x00007fd8b7db8000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fd8b7b9b000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fd8b7892000)
/lib64/ld-linux-x86-64.so.2 (0x00007fd8b9227000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fd8b768e000)
ex.php
<?php
try {
// Connecting to Ignite using pre-configured DSN.
$dbh = new \PDO('odbc:Driver=Apache Ignite;ADDRESS=127.0.0.1:10800;Cache =default');
// Changing PDO error mode.
$dbh->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
// Preparing query.
$dbs = $dbh->prepare('INSERT INTO city (id, name) VALUES (?, ?)');
// Declaring parameters.
$key = 777;
$firstName = "James";
// Binding parameters.
$dbs->bindParam(1, $key);
$dbs->bindParam(2, $firstName);
// Executing the query.
$dbs->execute();
} catch (PDOException $e) {
print "Error!: " . $e->getMessage() . "\n";
die();
}
?>
localhost/ex.php
Error!: SQLSTATE[01000] SQLDriverConnect: 0 [unixODBC][Driver Manager]Can't open lib '/usr/local/lib/libignite-odbc.so' : file not found
I do not know what to try.
Thank you for your help.

Try to use PHP Thin Client instead which requires fewer configuration efforts:
https://apacheignite.readme.io/docs/php-thin-client
If PHP PDO is still required then Ignite ODBC experts should step in.

Related

Symfony cloud MPDF temp files can't be stored in /tmp

Our project is going to be on Linux, and we want to have the temp files be stored in /tmp/mpdf. I have the following MPDF constructor:
$mpdf = new Mpdf(['mode' => 'en',
'default_font_size' => 8,
'margin_left' => 9.5,
'margin_right' => 0,
'margin_bottom' => 37,
'margin_header' => 0,
'margin_footer' => 2,
'fontDir' => array_merge((new ConfigVariables())->getDefaults()['fontDir'], [realpath(getenv('DOCUMENT_ROOT')) . '/../assets/fonts']),
'fontdata' => (new FontVariables())->getDefaults()['fontdata'] + [
'arialuni' => [
'R' => 'arialuni.ttf',
'B' => 'arialuni.ttf'
]
],
'tempDir' => sys_get_temp_dir()
]);
However, I end up getting the following error:
"[prod] Feb 26 10:40:30 |CRITICA| REQUES Uncaught PHP Exception Mpdf\MpdfException: "Temporary files directory "/app/vendor/mpdf/mpdf/src/Config/../../tmp/mpdf" is not writable" at /app/vendor/mpdf/mpdf/src/Cache.php line 21"
From what I understand, it still tries to use the following folder:
/app/vendor/mpdf/mpdf/tmp/mpdf
It should however use the /tmp folder which was recommended by the symfony cloud support (the /tmp folder of Linux)
So I had the same issue recently and it is caused by the Mpdf library not having enough permission to write to the vendors folder, (which frankly it shouldn't have).
The solution for me was to update the tmp_dir in ConfigVariables.php to use PHP's temp dir instead of the one it tries to use.
Made a fork => https://packagist.org/packages/tevli/mpdf
Github => https://github.com/tevli/mpdf

Qt - Module "QtQuick.Controls" is not installed

I try to deploy a QT application which works fine on a PC. The application is deployed in an image of a yocto installation, based on ASEM, with release "morty".
I receive the error message "qml: ERROR loading component: qrc:/GUI/InputDialog.qml:3 module "QtQuick.Controls" version 2.0 is not installed"
However, I don't see any trouble in the LDD output:
ldd $clientApp
linux-vdso.so.1 (0x7ed4b000)
libquazip.so.1 => /usr/lib/libquazip.so.1 (0x76f72000)
libQt5QuickWidgets.so.5 => /usr/lib/libQt5QuickWidgets.so.5 (0x76f64000)
libQt5Quick.so.5 => /usr/lib/libQt5Quick.so.5 (0x76c5e000)
libQt5Widgets.so.5 => /usr/lib/libQt5Widgets.so.5 (0x7674c000)
libQt5Gui.so.5 => /usr/lib/libQt5Gui.so.5 (0x762dd000)
libQt5Qml.so.5 => /usr/lib/libQt5Qml.so.5 (0x75f8d000)
libQt5Network.so.5 => /usr/lib/libQt5Network.so.5 (0x75e3d000)
libQt5Xml.so.5 => /usr/lib/libQt5Xml.so.5 (0x75e0d000)
libQt5Sql.so.5 => /usr/lib/libQt5Sql.so.5 (0x75dc1000)
libQt5Test.so.5 => /usr/lib/libQt5Test.so.5 (0x75d8c000)
libQt5Core.so.5 => /usr/lib/libQt5Core.so.5 (0x75861000)
libpthread.so.0 => /lib/libpthread.so.0 (0x75839000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x756f3000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x756c7000)
libc.so.6 => /lib/libc.so.6 (0x7558b000)
libGLESv2.so.2 => /usr/lib/libGLESv2.so.2 (0x75492000)
libm.so.6 => /lib/libm.so.6 (0x75414000)
libz.so.1 => /lib/libz.so.1 (0x753f2000)
libpng16.so.16 => /usr/lib/libpng16.so.16 (0x753ba000)
libmysqlclient.so.18 => /usr/lib/libmysqlclient.so.18 (0x750e9000)
libdl.so.2 => /lib/libdl.so.2 (0x750d6000)
libglib-2.0.so.0 => /usr/lib/libglib-2.0.so.0 (0x74fd7000)
librt.so.1 => /lib/librt.so.1 (0x74fc0000)
/lib/ld-linux-armhf.so.3 (0x76faa000)
libGAL.so => /usr/lib/libGAL.so (0x74ebc000)
libEGL.so.1 => /usr/lib/libEGL.so.1 (0x74e9d000)
libVSC.so => /usr/lib/libVSC.so (0x74ddb000)
libpcre.so.1 => /usr/lib/libpcre.so.1 (0x74d8c000)
libXdamage.so.1 => /usr/lib/libXdamage.so.1 (0x74d7a000)
libXfixes.so.3 => /usr/lib/libXfixes.so.3 (0x74d66000)
libXext.so.6 => /usr/lib/libXext.so.6 (0x74d48000)
libX11.so.6 => /usr/lib/libX11.so.6 (0x74c2e000)
libxcb.so.1 => /usr/lib/libxcb.so.1 (0x74c01000)
libXau.so.6 => /usr/lib/libXau.so.6 (0x74bef000)
libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0x74bdb000)
The offending line in the qml code is:
import QtQuick.Controls 2.0
Without any success, I have already added the following code to the recipe:
+IMAGE_INSTALL_append = " qtquickcontrols"
The directory /usr/lib/qt5/qml/QtQuick is present and contains libqtquick2plugin.so
Adding this directory to the LD_LIBRARY_PATH prior to starting the application does not solve the issue though.
I have exported:
export LD_LIBRARY_PATH=/usr/lib/qt5/qml/QtQuick.2:/usr/lib/qt5/qml/QtQuick
I wonder what file could be missing.
Can please somebody provide pointers on how to debug this?
To test Amfasis idea, I now also export
export QML2_IMPORT_PATH="/usr/lib/qt5/qml"
prior to starting the application in the same shell.
ls /usr/lib/qt5/qml/
Qt
QtGraphicalEffects
QtLocation
QtPositioning
QtQml
QtQuick
QtQuick.2
QtTest
QtWebChannel
QtWebEngine
builtins.qmltypes
Nevertheless, the error stays the same.
Looks as if I was missing libQt5QuickControls.so
I'll dig into this...
For future reference:
The idea is to explicitly state a dependency in yocto.
This can be achieved by adding
RDEPENDS_${PN} = "qtquickcontrols2 \
qtquickcontrols2-mkspecs \
"
Then, the dependency will be compiled and installed.
It is not enough, though, to add the following (which I had before already):
DEPENDS = "qtquickcontrols2"
I followed this answer:
sudo apt install qml-module-qtquick-controls2
Note the 2 at the end. By default minuet package installs qml-module-qtquick-controls.
And fixed the errors running minuet 19.12.3-0ubuntu1 on Ubuntu 20.04:
[...]
QQmlApplicationEngine failed to load component
qrc:/Main.qml:24 module "QtQuick.Controls" version 2.0 is not installed

ldd: Library cannot be found

I am running ldd command on libqqnx.so on my target board. This list few certain dependent libraries and then throw error called ldd: Library cannot be found. If I do same on libcpp.so.4 of qnx then it does not show such errors.
My question is, the file libqqnx.so is corrupted or should it be listing some more dependent lib files?
output1:
# ldd /opt/qt/plugins/platforms/libqqnx.so:
libqqnx.so => /opt/qt/plugins/platforms/libqqnx.so (0x78000000)
libscreen.so.1 => /proc/boot/libscreen.so.1 (0x78040000)
libpps.so.1 => /opt/qt/lib/libpps.so.1 (0x78031000)
libm.so.2 => /proc/boot/libm.so.2 (0x78060000)
libfreetype.so.1 => /usr/lib/libfreetype.so.1 (0x78090000)
libQt5DBus.so.5 => /opt/qt/lib/libQt5DBus.so.5 (0x780e0000)
libQt5Gui.so.5 => /opt/qt/lib/libQt5Gui.so.5 (0x78200000)
libQt5Core.so.5 => /opt/qt/lib/libQt5Core.so.5 (0x78600000)
libGLESv2.so.1 => /usr/lib/graphics/iMX6X/libGLESv2.so.1 (0x78037000)
libEGL.so.1 => /proc/boot/libEGL.so.1 (0x78053000)
libcpp.so.5 => /opt/qt/lib/libcpp.so.5 (0x78140000)
libz.so.2 => /proc/boot/libz.so.2 (0x781a0000)
libslog2.so.1 => /proc/boot/libslog2.so.1 (0x78083000)
libicui18n.so.49 => /opt/qt/lib/libicui18n.so.49 (0x78a00000)
libicuuc.so.49 => /opt/qt/lib/libicuuc.so.49 (0x78b10000)
libicudata.so.49 => /opt/qt/lib/libicudata.so.49 (0x78c00000)
ldd: Library cannot be found
output2:
# ldd /proc/boot/libcpp.so.4:
libcpp.so.4 => /proc/boot/libcpp.so.4 (0x78000000)
#
It looks for me that ldd is looking for more libraries but it doesn't find them.
If you know another directory that has other libraries (.so* files) allow qnx to search on it for the missing libraries. You can use LD_LIBRARY_PATH.
For example: export LD_LIBRARY_PATH=/opt/qt/some_dir
More info here

How can I fix an apparent Qt4 / Qt5 conflict?

I recently installed Qt4 even though I already had some Qt5 libraries installed, because an application seemed to require Qt4. Tragically, that application also used mayavi, which would now segfault when it tried to import its mlab module. I managed to isolate the cause of the segfault to the following imports, both of which are necessary to cause the crash:
me#Bedrock:~$ python
Python 2.7.12 (default, Nov 19 2016, 06:48:10)
[GCC 5.4.0 20160609] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import vtk
>>> from pyface import api as pyface
QMetaType::registerType: Binary compatibility break -- Size mismatch for type 'QUuid' [30]. Previously registered size 16, now registering size 0.
Aborted (core dumped)
me#Bedrock:~$
Googling around has led to some suggestions as to how to set environment variables in .bashrc :
export QTCHOOSER_RUNTOOL=qtconfig
export QT_SELECT=4
export QT_API='pyside'
export ETS_TOOLKIT='qt4'
I've used these, somewhat blindly, but without success.
Am I correct in believing my problems are due to a Qt4/Qt5 conflict, and if so, what should I do about it?
=============================================================================
I've investigated a little further. I now can get this crash with the following two imports:
me#Bedrock:~/Downloads/temp3/mne-python$ python
Python 2.7.12 (default, Nov 19 2016, 06:48:10)
[GCC 5.4.0 20160609] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from vtk.vtkCommonCore import *
>>> from PySide.QtGui import *
QMetaType::registerType: Binary compatibility break -- Size mismatch for type 'QUuid' [30]. Previously registered size 16, now registering size 0.
Aborted (core dumped)
vtk.vtkCommonCorecontains a single line, which imports vtkCommonCorePython, and this is an .so file.
Similarly, PySide.QtGui is also a .so file.
So, my next step was to see which .so files /usr/local/lib/python2.7/dist-packages/PySide/QtGui.so and /usr/lib/python2.7/dist-packages/vtk/vtkCommonCorePython.x86_64-linux-gnu.so depend upon.
What I found was this:
me#Bedrock:/usr/lib/python2.7/dist-packages/vtk$ ldd -v vtkCommonCorePython.x86_64-linux-gnu.so
linux-vdso.so.1 => (0x00007fff28fc0000)
libvtkCommonCorePython27D-6.2.so.6.2 => /usr/lib/x86_64-linux-gnu/libvtkCommonCorePython27D-6.2.so.6.2 (0x00007f0488925000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f04885a2000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f04881d9000)
libvtkWrappingPython27Core-6.2.so.6.2 => /usr/lib/x86_64-linux-gnu/libvtkWrappingPython27Core-6.2.so.6.2 (0x00007f0487fac000)
libvtkCommonCore-6.2.so.6.2 => /usr/lib/x86_64-linux-gnu/libvtkCommonCore-6.2.so.6.2 (0x00007f0487a7d000)
libpython2.7.so.1.0 => /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0 (0x00007f04874ef000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f04871e6000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f0486fcf000)
/lib64/ld-linux-x86-64.so.2 (0x000055b9eee1f000)
libvtksys-6.2.so.6.2 => /usr/lib/x86_64-linux-gnu/libvtksys-6.2.so.6.2 (0x00007f0486d8a000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f0486b6c000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f0486952000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f048674e000)
libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 (0x00007f048654a000)
and this:
me#Bedrock:/usr/local/lib/python2.7/dist-packages/PySide$ ldd -v /usr/local/lib/python2.7/dist-packages/PySide/QtGui.so
linux-vdso.so.1 => (0x00007fff37bfc000)
libpyside-python2.7.so.1.2 (0x00007ff4672cf000)
libpython2.7.so.1.0 => /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0 (0x00007ff466cfa000)
libshiboken-python2.7.so.1.2 (0x00007ff466ac6000)
libQtGui.so.4 => /usr/lib/x86_64-linux-gnu/libQtGui.so.4 (0x00007ff465dd2000)
libQtCore.so.4 => /usr/lib/x86_64-linux-gnu/libQtCore.so.4 (0x00007ff4658de000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007ff46555c000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007ff465346000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007ff464f7c000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007ff464d5f000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007ff464b45000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007ff464940000)
libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 (0x00007ff46473d000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007ff464434000)
libfontconfig.so.1 => /usr/lib/x86_64-linux-gnu/libfontconfig.so.1 (0x00007ff4641f0000)
libaudio.so.2 => /usr/lib/x86_64-linux-gnu/libaudio.so.2 (0x00007ff463fd7000)
libglib-2.0.so.0 => /lib/x86_64-linux-gnu/libglib-2.0.so.0 (0x00007ff463cc6000)
libpng12.so.0 => /lib/x86_64-linux-gnu/libpng12.so.0 (0x00007ff463aa0000)
libfreetype.so.6 => /usr/lib/x86_64-linux-gnu/libfreetype.so.6 (0x00007ff4637f6000)
libgobject-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 (0x00007ff4635a3000)
libSM.so.6 => /usr/lib/x86_64-linux-gnu/libSM.so.6 (0x00007ff46339a000)
libICE.so.6 => /usr/lib/x86_64-linux-gnu/libICE.so.6 (0x00007ff463180000)
libXi.so.6 => /usr/lib/x86_64-linux-gnu/libXi.so.6 (0x00007ff462f70000)
libXrender.so.1 => /usr/lib/x86_64-linux-gnu/libXrender.so.1 (0x00007ff462d65000)
libXext.so.6 => /usr/lib/x86_64-linux-gnu/libXext.so.6 (0x00007ff462b53000)
libX11.so.6 => /usr/lib/x86_64-linux-gnu/libX11.so.6 (0x00007ff462819000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007ff462610000)
/lib64/ld-linux-x86-64.so.2 (0x000055bd99ece000)
libexpat.so.1 => /lib/x86_64-linux-gnu/libexpat.so.1 (0x00007ff4623e7000)
libXt.so.6 => /usr/lib/x86_64-linux-gnu/libXt.so.6 (0x00007ff46217d000)
libXau.so.6 => /usr/lib/x86_64-linux-gnu/libXau.so.6 (0x00007ff461f79000)
libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 (0x00007ff461d09000)
libffi.so.6 => /usr/lib/x86_64-linux-gnu/libffi.so.6 (0x00007ff461b00000)
libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1 (0x00007ff4618fb000)
libxcb.so.1 => /usr/lib/x86_64-linux-gnu/libxcb.so.1 (0x00007ff4616d8000)
libXdmcp.so.6 => /usr/lib/x86_64-linux-gnu/libXdmcp.so.6 (0x00007ff4614d2000)
Only /usr/local/lib/python2.7/dist-packages/PySide/QtGui.so seems to have any direct connection to the Qt libraries, so I don't understand how/why the vtk import interferes with anything Qt related.
Finally, I became curious about which version of Qt the /usr/lib/x86_64-linux-gnu/libQt...so files were using. So, I tried this:
me#Bedrock:~$ qmake --version
QMake version 2.01a
Using Qt version 4.8.7 in /usr/lib/x86_64-linux-gnu
I also checked my version of vtk
>>> vtk.VTK_MAJOR_VERSION
6
>>> vtk.VTK_MINOR_VERSION
2
>>>
and, separately, my version of PySide:
>>> import PySide
>>> PySide.__version__
'1.2.4'
At this point, I'm only more puzzled. Is my problem a Qt4/Qt5 conflict? (I think so) If not, why do I get Seg Faults with the error :
QMetaType::registerType: Binary compatibility break -- Size mismatch for type 'QUuid' [30]. Previously registered size 16, now registering size 0.
Aborted (core dumped)
If so, why do I only seem to be using one version of Qt? Most importantly, how can I fix this?
With default configurations of Qt builds, a given process can only use one version of Qt. If you're loading a Python module that uses Qt 5, and another that uses Qt 4, there will be issues as plenty of symbols overlap.
To use Qt 4 in parallel with Qt 5 in an application, you must compile one of the Qt versions in its own namespace, and rebuild the module(s) that use that Qt version. That way the symbols won't clash and the same process can use multiple Qt versions.

Environment for a Qt Program

I have a Qt executable file.
When this program runs on a Ubuntu 11.04 virtual machine, the GUI is ugly though you can still tell it is the GUI that you want. When it runs on Ubuntu 12.04 of my laptop, however, everything goes well. Thus I guess there might be something wrong with the environment of the virtual machine.
To find out whether the problem lies in the libraries, I ran the command
ldd filename
I got library dependencies as following:
% Below is the output on the virtual machine
linux-gate.so.1 => (0x00cc8000)
libQtGui.so.4 => /opt/qt-4.7.1x86/lib/libQtGui.so.4 (0x00cc9000)
libQtCore.so.4 => /opt/qt-4.7.1x86/lib/libQtCore.so.4 (0x00110000)
libpthread.so.0 => /lib/i386-linux-gnu/libpthread.so.0 (0x003b6000)
libstdc++.so.6 => /usr/lib/i386-linux-gnu/libstdc++.so.6 (0x003cf000)
libm.so.6 => /lib/i386-linux-gnu/libm.so.6 (0x004ba000)
libgcc_s.so.1 => /lib/i386-linux-gnu/libgcc_s.so.1 (0x004e0000)
libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0x004fc000)
libXext.so.6 => /usr/lib/i386-linux-gnu/libXext.so.6 (0x00686000)
libX11.so.6 => /usr/lib/i386-linux-gnu/libX11.so.6 (0x00695000)
libdl.so.2 => /lib/i386-linux-gnu/libdl.so.2 (0x0065d000)
librt.so.1 => /lib/i386-linux-gnu/librt.so.1 (0x007b0000)
/lib/ld-linux.so.2 (0x00668000)
libxcb.so.1 => /usr/lib/i386-linux-gnu/libxcb.so.1 (0x00a96000)
libXau.so.6 => /usr/lib/i386-linux-gnu/libXau.so.6 (0x009ed000)
libXdmcp.so.6 => /usr/lib/i386-linux-gnu/libXdmcp.so.6 (0x008a8000)
% Below is the output on Ubuntu 12.04 of my laptop
linux-gate.so.1 => (0xb776f000)
libQtGui.so.4 => /usr/lib/i386-linux-gnu/libQtGui.so.4 (0xb6c8a000)
libQtCore.so.4 => /usr/lib/i386-linux-gnu/libQtCore.so.4 (0xb69ad000)
libpthread.so.0 => /lib/i386-linux-gnu/libpthread.so.0 (0xb6991000)
libstdc++.so.6 => /usr/lib/i386-linux-gnu/libstdc++.so.6 (0xb68ac000)
libm.so.6 => /lib/i386-linux-gnu/libm.so.6 (0xb6880000)
libgcc_s.so.1 => /lib/i386-linux-gnu/libgcc_s.so.1 (0xb6862000)
libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xb66bd000)
libfontconfig.so.1 => /usr/lib/i386-linux-gnu/libfontconfig.so.1 (0xb6688000)
libaudio.so.2 => /usr/lib/i386-linux-gnu/libaudio.so.2 (0xb666f000)
libglib-2.0.so.0 => /lib/i386-linux-gnu/libglib-2.0.so.0 (0xb6576000)
libpng12.so.0 => /lib/i386-linux-gnu/libpng12.so.0 (0xb654c000)
libz.so.1 => /lib/i386-linux-gnu/libz.so.1 (0xb6536000)
libfreetype.so.6 => /usr/lib/i386-linux-gnu/libfreetype.so.6 (0xb649b000)
libgobject-2.0.so.0 => /usr/lib/i386-linux-gnu/libgobject-2.0.so.0 (0xb644c000)
libSM.so.6 => /usr/lib/i386-linux-gnu/libSM.so.6 (0xb6443000)
libICE.so.6 => /usr/lib/i386-linux-gnu/libICE.so.6 (0xb6429000)
libXi.so.6 => /usr/lib/i386-linux-gnu/libXi.so.6 (0xb6419000)
libXrender.so.1 => /usr/lib/i386-linux-gnu/libXrender.so.1 (0xb640e000)
libXext.so.6 => /usr/lib/i386-linux-gnu/libXext.so.6 (0xb63fc000)
libX11.so.6 => /usr/lib/i386-linux-gnu/libX11.so.6 (0xb62c8000)
libdl.so.2 => /lib/i386-linux-gnu/libdl.so.2 (0xb62c3000)
librt.so.1 => /lib/i386-linux-gnu/librt.so.1 (0xb62ba000)
/lib/ld-linux.so.2 (0xb7770000)
libexpat.so.1 => /lib/i386-linux-gnu/libexpat.so.1 (0xb628f000)
libXt.so.6 => /usr/lib/i386-linux-gnu/libXt.so.6 (0xb6233000)
libXau.so.6 => /usr/lib/i386-linux-gnu/libXau.so.6 (0xb622f000)
libpcre.so.3 => /lib/i386-linux-gnu/libpcre.so.3 (0xb61f3000)
libffi.so.6 => /usr/lib/i386-linux-gnu/libffi.so.6 (0xb61ec000)
libuuid.so.1 => /lib/i386-linux-gnu/libuuid.so.1 (0xb61e5000)
libxcb.so.1 => /usr/lib/i386-linux-gnu/libxcb.so.1 (0xb61c4000)
libXdmcp.so.6 => /usr/lib/i386-linux-gnu/libXdmcp.so.6 (0xb61bd000)
Then I am wondering how can they be different? Can I find out what is wrong by tools such as strace?
I can see that Qt is installed in /opt on your 11.04. I guess that means you've built it yourself? Two solutions here:
Install Qt from Ubuntu's repository instead. It comes with the needed Gtk style. (Note that 11.04 also has Qt available; it's just that 12.04 installs it by default while 11.04 doesn't.)
When you build Qt, make sure to enable the Gtk style by passing the "-gtkstyle" option to the configure script. You will probably need to have all needed development packages for Gtk installed.
The display of text in the program is too ugly to be simply a problem of style. But the problem indeed lies in the process of building Qt. When I ran ./configure, I output the configure information into a log file and found things like
88 Xinerama support ....... no
89 Xcursor support ........ no
90 Xfixes support ......... no
91 Xrandr support ......... no
92 Xrender support ........ no
93 Xi support ............. no
Moreover, I found the Qt for X11 requirements here. Therefore I concluded that the problem lies in a lack of such libraries. And fortunately, everything works fine after installing them.

Resources