QTX4.4.3: Host build (-qvfb) produces unrunnable qpe

[uberbubba]

Intel P4, Linux FC7, gcc4.1.2, qt-x11: 4.3.3, qt-extended-4.4.3

Hi there, I'm new to the forum and to Qt. Love what you've got going here. I'm trying to build a host image and SDK of a device using Qt Extended 4.4.3. I used the instructions here:

Creating and using binary SDKs
(http://doc.trolltech.com/qtextended4...ry-sdks-1.html)

I followed the instructions exactly (with a slightly different SDK and image path) yet when I runqtopia in my app directory, I always get the following message from qpe:

>************************************************* *********
>* ERROR: Expecting this binary to be located in
>* /opt/qt/sdk/qt-extended-4.4.3/i386/qtopiacore/target/bin/qpe
>* but it is being run from
>* /opt/qt/sdk/qt-extended-4.4.3/i386/image/bin/qpe
>*
>* This generally indicates that you have specified the wrong
>* value for -prefix when configuring Qtopia. Based on the
>* location of this binary, you should be using a prefix of
>*
>************************************************* *********
>
>Unable to initialize task subsystem. Please check '/opt/qt/sdk/qt-extended-4.4.3/i386/qtopiacore/target//etc/Tasks.cfg' exists and its content is valid.
>/tmp/runqtopia.11238: line 26: 11246 Aborted $qpe "$@"

It showed my device skin then died leaving the skin up. Note that the error message gives a blank "suggested" prefix.

My configure command reads so:

/opt/qt/qt-extended-4.4.3/configure -image /opt/qt/sdk/qt-extended-4.4.3/i386/image -device mydevice -confirm-license -qvfb -sdk /opt/qt/sdk/qt-extended-4.4.3/i386

However, configure later executes the following:

configure -embedded i386 -platform linux-g++ -xplatform qws/linux-generic-g++ -prefix
/opt/qt/sdk/qt-extended-4.4.3/i386/qtopiacore/target -make src -make tools -no-stl -no-exceptions -no-xmlpatterns -no-qt3support -no-glib -no-cups -no-dbus -no-accessibility -nomake examples -nomake demos -nomake docs -DQT_QWS_DISABLE_FLUSHCLIPPING -confirm-license -depths 8,16,18,24,32 -qconfig qpe -DQT_NO_PLUGIN_CHECK -DQT_EXTERNAL_SOUND_SERVER -DQT_QWS_KEYEVENT_SINGLECLIENT -force-pkg-config -no-sql-ibase -no-sql-mysql -no-sql-odbc -no-sql-psql -no-sql-sqlite -no-sql-sqlite2 -qt-sql-sqlite
-release -qt-gfx-qvfb -qt-mouse-qvfb -qt-kbd-qvfb -qt-gif -DMEDIA_SERVER -no-rpath -no-separate-debug-info -DQT_KEYPAD_NAVIGATION -dbus -DQT_QWS_CLIENTBLIT -little-endian -no-webkit

The "prefix" given by the Embedded config appears to be the one it wants to use, not the one implied by "-image". In other build attempts I have explicitly specified "-prefix" and "-hostprefix" etc., and I have done a "qbuild image IMAGE=/opt/qt/sdk/qt-extended-4.4.3/i386/image", with the same results. It seems determined to use the path from the Embedded config.

I looked at the qtopiacore QLibraryInfo class code to try to find out why it failed. There I discovered the possibility of using qt.conf to change the PrefixPath, but that turned out to be a dead end. It didn't read or even try to find qt.conf before it croaked (this I saw from the strace.out).

Same problem on QT Extended 4.4.2.

I've been beating my head against this one for longer than I want to admit. I'm pretty sure it's a configuration problem because I don't see anyone else yelling about it. Does anyone see where I screwed up?

Thanks in advance,

-Jim

[uberbubba]

Just to wrap this up...

I submitted this as a bug to Qt. Within days they responded with a patch. Below is the salient part of the dialog I had with one of their senior software engineers. If you have this problem you should be able to diagnose it with his suggestions below.

After applying the patch, you may only have to 'qbuild image' in the build directory. I wanted to start over so I completely wiped the SDK directory as well as the build directory. Once everything was rebuilt it worked perfectly.

-----------------------------------------------------------------------
> I took my device configuration largely from the Greenphone, but with
> > generous helpings of the N810 thrown in...

The Greenphone sets -prefix /opt/Qtopia in configure because that's
where it runs on the device. When doing a -qvfb build, it runs from
wherever the image is. The Greenphone uses -no-rpath because it needs
to use LD_LIBRARY_PATH to allow libs to be in /home/updates/lib
and /opt/Qtopia/lib but the device ignores LD_LIBRARY_PATH when an
RPATH is set (this is a bit strange, I'm not really sure why it happens
but it does seem unique to this embedded environment, LD_LIBRARY_PATH
works fine on desktop systems).
...
>> Do you have LD_LIBRARY_PATH set? Are you able to verify that
>> > > <image>/bin/qpe is linking to
>> > > <image>/qtopiacore/target/lib/libQtCore.so and not to
>> > > <sdk>/qtopiacore/target/lib/libQtCore.so at runtime?
>> > >
> > I run with LD_LIBRARY_PATH set to /opt/qt/sdk/4.4.3/x86/image/lib.
> > Below is the ldd output. It appears that the core libraries are
> > linking from the SDK, not the image.

Ok... your desktop system is exhibiting the same problem that the
Greenphone exhibits. It is ignoring LD_LIBRARY_PATH in preference for
the embedded RPATH.

On my system qpe has an RPATH (even though it shouldn't) and this RPATH
allows it to find the Qt Embedded libs from the SDK. Setting
LD_LIBRARY_PATH (like runqtopia does) makes qpe find the correct
libraries. In your case, LD_LIBRARY_PATH is required for all of the Qt
Extended libraries but it is not overriding the RPATH so the wrong Qt
libraries are being used.

You can verify that qpe has an RPATH by running objdump -x
<image>/bin/qpe | grep RPATH

>> > > If you run: strings <image>/qtopiacore/target/lib/libQtCore.so |
>> > > grep qt_prfxpath what do you see?
>> > >
> > qt_prfxpath=/opt/qt/sdk/4.4.3/x86/image
> >
> > Looks like the correct image location in the image's libQtCore. qpe
> > just doesn't want to load it.

I'm not sure why your system is not doing the right thing with
LD_LIBRARY_PATH but the fact that an RPATH was set on qpe is a bug so I
will see if I can track this down and provide a fix to you.