Revert to pkg-config

[pini-gh]

Hi Radek,

Here is a first candidate pull request, successfully tested on a Debian Wheezy + gcc-4.6 pdebuild-cross configuration.

I'll need some more time to check a build on Squeeze + gcc-4.4.

Thanks,

_g.

[radekp]

Hi, from my current experience we should not use -system-qt now and dont depend on libqt4-dev. Instead we should use -build-qt and use the qt in build/qtopiacore/host.

I have several reasons for it. First it's quite hard to support all possible host qt versions (squeeze, wheezy, fedora whatever) and also bugs in host qt can affect also the target build - because some files are generated by host tools that use host qt.

The seconds reason is that the qt embedded libraries for target have same name and as host qt and they are easily confused with host qt - this is probably why override_dh_shlibdeps does not work for native builds.

So should i pull the patch as is and then later remove the libqt4-dev dependency or would you like to prepare newer patch version?

Regards

Radek

[pini-gh]

I think we should try to straightforward the build process as much as we can, and allowing -system-qt is part of this effort. At least, I'd prefer to let the choice to the user. Anyway, the relevant hosts for building the qtmoko packages are Debian based (pure chroot or pdebuild chroot). So I'd prefer having "-build-qt" in debian/rules - if necessary - and README than forced in configure-common for all cases.

Do you remenber which files could be corrupted by using -system-qt? It's worth investigating imho.

By the way, is the - soon to be deprecated - squeeze target worth the effort still (still trying to solve dependencies for the squeeze build...)?

[radekp]

I think -build-qt option in configure-common does not prevent building with -system-qt. If you explicitly tell configure -system-qt it will override -build-qt - at least this is how it works for me. So building with -system-qt should now be still possible.

As for building the debian package - i am going to use -build-qt for qtmoko native arm releases, but i dont mind if it is configurable or is it is -system-qt for cross compiling.

The corrupted file was in this case qtopia_db.sqlite. It was bug that i made in QFileInfo which caused invalid parsing of desktop files and resulted in qtmoko without icons for applications.

Btw why should be squeeze deprecated? I am not sure if we are ready for wheezy yet...

[pini-gh]

The reason for I'm in favor of -system-qt is that it significantly shorten the build duration.

Now that you've fixed that bug, is there a risk for a corrupted qtopia_db.sqlite again with -system-qt? Making -build-qt / -system-qt configurable will heavily bloat the debian source package (different Build-depends at least).

Btw why should be squeeze deprecated? I am not sure if we are ready for wheezy yet...

Just throwing a line ;P It's quite some work to cope with several major targets. Wheezy is frozen now, and Squeeze will become old-stable as soon as Wheezy is released (late 2012 / early 2013). And my GTA04 runs Wheezy armhf for a few weeks without noticeable problems so far.

[radekp]

Ahh i thought that wheezy is years away :) Maybe we can do last squeeze based release and move to wheezy then... I also do not like supporting more targets, but i am afraid there are things to be solved before we can move to wheezy. E.g. wpa_supplicant from wheezy does not work on GTA02 (there was mail from lindi on ML about it...)

If system qt is broken it can always do problems. I also wonder what will happen when distros will start shipping Qt 5 and will deprecate Qt 4. As far as i know Qt 5 has some hard dependencies on opengl acceleration, which is probably no way for us.

So now i wonder if we could make package both ways - either with -build-qt (which i would like to use for releases) and -system-qt so that it builds fast...

[pini-gh]

As for building the debian package - i am going to use -build-qt for qtmoko native arm releases, but i dont mind if it is configurable or is it is -system-qt for cross compiling.

Now that Squeeze support is back, I'll make -build-qt the default again and add support for -system-qt through some environment variable. Should be ready by tomorrow (hope so).

[pini-gh]

Radek, it fails badly with -build-qt, at the "Testing QBuild: Running config test qbuild_sanity" step. The command being run is:

/tmp/buildd/qtmoko-49/src/build/bin/runwithvars.sh DEVICE_CONFIG_PATH=/tmp/buildd/build-gta04/sdk/devices/gta04 DEFAULT_DEVICE_PATH=/tmp/buildd/build-gta04/sdk/devices/default DEVICE_BIN=/tmp/buildd/build-gta04/sdk/devices/gta04/device_bin DEVICE_BUILDING_FOR_DESKTOP=0 MAKE=make /tmp/buildd/build-gta04/sdk/bin/qbuild.bin -script -j1 -v

And it segfaults :(

Does it ring a bell? My current configuration is a Wheezy cross-build chroot for armhf with gcc-4.6.

[pini-gh]

Here are the last lines from ltrace ouput of the faulting command:

 QSettings::QSettings(QString const&, QSettings::Format, QObject*)(0x7fff079346d0, 0x7fff079344c0, 1, 0, 0x6e006f00690074 <unfinished ...>
  QHashData::rehash(int)(0x1948110, 1, 0, 0x1947cd0, 0x1948100) = 0
  QFile::fileEngine() const(0x7fff07934240, 0x1947cd0, 0x7fff07934240, 0x1948440, 0x7f6ffebb0ed8) = 0x1948140
  SYS_lstat("/tmp/buildd/build-gta04/qbuild.solution", 0x7fff07933d50) = 0
  QFile::fileEngine() const(0x7fff07934240, 1, 0x7fff07934240, 0x7fff07934270, 0x6e006f00690074) = 0x1948140
  SYS_open("/tmp/buildd/build-gta04/qbuild.solution", 655360, 0666) = 6
  SYS_fcntl(6, 2, 1, 0, 1)                       = 0
  SYS_fstat(6, 0x7fff07933e10)                   = 0
  SYS_fstatfs(6, 0x7fff079340e0)                 = 0
--- SIGSEGV (Segmentation fault) ---

[radekp]

On Friday, November 09, 2012 03:03:18 PM pini-gh wrote:

Radek, it fails badly with -build-qt, at the "Testing QBuild: Running config test qbuild_sanity" step. The command being run is: /tmp/buildd/qtmoko-49/src/build/bin/runwithvars.sh DEVICE_CONFIG_PATH=/tmp/buildd/build-gta04/sdk/devices/gta04 DEFAULT_DEVICE_PATH=/tmp/buildd/build-gta04/sdk/devices/default DEVICE_BIN=/tmp/buildd/build-gta04/sdk/devices/gta04/device_bin DEVICE_BUILDING_FOR_DESKTOP=0 MAKE=make /tmp/buildd/build-gta04/sdk/bin/qbuild.bin -script -j1 -v And it segfaults :(

Does it ring a bell? My current configuration is a Wheezy cross-build chroot for armhf with gcc-4.6.

Hmm can you please try with qt 4.7? It should be enough to go to qtopiacore/qt and do git checkout v4.7.4-qtmoko-v46

Regards

Radek

[pini-gh]

Unfortunately the behavior is the very same with qt 4.7:

*******************************************************************************
Qt is ready!
*******************************************************************************

Testing the system Qt: OK
Qt Extended is using the following locations:
Qt          PREFIX      = /tmp/buildd/build-gta04/sdk/qtopiacore/host
Qt          LIBRARIES   = /tmp/buildd/build-gta04/sdk/qtopiacore/host/lib
Qt          BINARIES    = /tmp/buildd/build-gta04/sdk/qtopiacore/host/bin
Qt          HEADERS     = /tmp/buildd/build-gta04/sdk/qtopiacore/host/include
Qt Embedded SOURCE tree = /tmp/buildd/qtmoko-49/qtopiacore/qt
Qt Embedded BUILD  tree = /tmp/buildd/build-gta04/qtopiacore/target
Qt Extended SOURCE tree = /tmp/buildd/qtmoko-49
Qt Extended BUILD  tree = /tmp/buildd/build-gta04
Qt Extended SDK    tree = /tmp/buildd/build-gta04/sdk

Checking the compiler (host): OK (GCC 4, Little Endian)
Checking the compiler (target): OK (Little Endian)
Bootstrap QBuild: ............................... OK
Testing QBuild: FAIL
ERROR: Cannot continue without QBuild.

And:

pbuilder@pinizbox:~/qtmoko-49$ cd ../build-gta04/
pbuilder@pinizbox:~/build-gta04$ ./sdk/bin/qbuild.bin 
Segmentation fault

[radekp]

Hmm i have just tried squeeze + emdebian armel cross toolchain. On this combination -build-qt works just fine. I can try wheezy + armel toochain tool easily too. I'll report soon how if it worked.

[pini-gh]

Indeed, I can confirm that squeeze + armel + gcc-4.4 passes the "Testing QBuild" step successfully. Will try wheezy + armel + gcc-4.4.

[pini-gh]

Wheezy + armel + gcc-4.4 fails the same way as previous wheezy tries: qbuild.bin segfaults.

[radekp]

here too, it looks like something in javascript from the backtrace:

(gdb) r Starting program: /home/radek/qte/build-wheezy/sdk/bin/qbuild.bin [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". ASSERTION FAILED: m_freePtr <= m_end (/home/radek/qte/qtmoko/qtopiacore/qt/src/3rdparty/javascriptcore/JavaScriptCore/jit/ExecutableAllocator.h:102 void* QTJSC::ExecutablePool::alloc(size_t))

Program received signal SIGSEGV, Segmentation fault. 0x00007ffff76e81e6 in QTJSC::ExecutablePool::alloc (this=0x6f3200, n=552) at /home/radek/qte/qtmoko/qtopiacore/qt/src/3rdparty/javascriptcore/JavaScriptCore/jit/ExecutableAllocator.h:102 102 ASSERT(m_freePtr <= m_end); (gdb) bt

0 0x00007ffff76e81e6 in QTJSC::ExecutablePool::alloc (this=0x6f3200, n=552)

at /home/radek/qte/qtmoko/qtopiacore/qt/src/3rdparty/javascriptcore/JavaScriptCore/jit/ExecutableAllocator.h:102

1 0x00007ffff76e8917 in QTJSC::AssemblerBuffer::executableCopy (this=0x7fffffffccc0, allocator=0x6f3200)

at /home/radek/qte/qtmoko/qtopiacore/qt/src/3rdparty/javascriptcore/JavaScriptCore/assembler/AssemblerBuffer.h:132

2 0x00007ffff76e8d2b in QTJSC::X86Assembler::X86InstructionFormatter::executableCopy (this=0x7fffffffccc0, allocator=0x6f3200)

at /home/radek/qte/qtmoko/qtopiacore/qt/src/3rdparty/javascriptcore/JavaScriptCore/assembler/X86Assembler.h:1885

3 0x00007ffff76e8ca9 in QTJSC::X86Assembler::executableCopy (this=0x7fffffffccc0, allocator=0x6f3200)

at /home/radek/qte/qtmoko/qtopiacore/qt/src/3rdparty/javascriptcore/JavaScriptCore/assembler/X86Assembler.h:1583

4 0x00007ffff76e9759 in QTJSC::LinkBuffer::LinkBuffer (this=0x7fffffffc6e0, masm=0x7fffffffccc0, executablePool=...)

at /home/radek/qte/qtmoko/qtopiacore/qt/src/3rdparty/javascriptcore/JavaScriptCore/assembler/LinkBuffer.h:67

5 0x00007ffff76ed31d in QTJSC::JIT::privateCompileCTIMachineTrampolines (this=0x7fffffffccc0, executablePool=0x6f1008, globalData=0x6efe20, ctiStringLengthTrampoline=0x6f1010,

ctiVirtualCallLink=0x6f1018, ctiVirtualCall=0x6f1020, ctiNativeCallThunk=0x6f1028)
at /home/radek/qte/qtmoko/qtopiacore/qt/src/3rdparty/javascriptcore/JavaScriptCore/jit/JITOpcodes.cpp:1817

6 0x00007ffff7706e16 in QTJSC::JIT::compileCTIMachineTrampolines (globalData=0x6efe20, executablePool=0x6f1008, ctiStringLengthTrampoline=0x6f1010, ctiVirtualCallLink=0x6f1018,

ctiVirtualCall=0x6f1020, ctiNativeCallThunk=0x6f1028) at /home/radek/qte/qtmoko/qtopiacore/qt/src/3rdparty/javascriptcore/JavaScriptCore/jit/JIT.h:323

7 0x00007ffff76fb5ce in QTJSC::JITThunks::JITThunks (this=0x6f1008, globalData=0x6efe20)

at /home/radek/qte/qtmoko/qtopiacore/qt/src/3rdparty/javascriptcore/JavaScriptCore/jit/JITStubs.cpp:768

8 0x00007ffff77512e6 in QTJSC::JSGlobalData::JSGlobalData (this=0x6efe20, isShared=false)

at /home/radek/qte/qtmoko/qtopiacore/qt/src/3rdparty/javascriptcore/JavaScriptCore/runtime/JSGlobalData.cpp:148

9 0x00007ffff775188d in QTJSC::JSGlobalData::create () at /home/radek/qte/qtmoko/qtopiacore/qt/src/3rdparty/javascriptcore/JavaScriptCore/runtime/JSGlobalData.cpp:205

10 0x00007ffff77d7b7a in QScriptEnginePrivate::QScriptEnginePrivate (this=0x6ee640) at /home/radek/qte/qtmoko/qtopiacore/qt/src/script/api/qscriptengine.cpp:979

11 0x00007ffff77dcbf6 in QScriptEngine::QScriptEngine (this=0x6eb410, parent=0x7fffffffe0d0) at /home/radek/qte/qtmoko/qtopiacore/qt/src/script/api/qscriptengine.cpp:1976

12 0x00000000004a0788 in StartupEngine (parent=0x7fffffffe0d0, this=0x6eb410) at ../../../qtmoko/qbuild/src/startup.cpp:188

13 StartupScript::StartupScript (this=0x7fffffffe0d0, appname=, parent=) at ../../../qtmoko/qbuild/src/startup.cpp:558

14 0x0000000000426ea4 in main (_argc=, _argv=) at ../../../qtmoko/qbuild/src/main.cpp:528

[pini-gh]

What configure options do you use? I have nothing useful in the backtrace:

Program received signal SIGSEGV, Segmentation fault.
0x0000000000000000 in ?? ()
(gdb) bt
#0  0x0000000000000000 in ?? ()
#1  0x0000000000000000 in ?? ()

My configure options are:

-device gta04 -xplatform linux-native-g++ -remove-module pkgmanagement \
 -extra-qt-embedded-config="-verbose -system-sqlite -system-libtiff -system-libmng" \
 -extra-qt-config="-debug -system-sqlite -no-gif -nomake tools -no-declarative"

[radekp]

I just did ../qtmoko/configure -force-build-qt -device gta04 -verbose

I have added -force-build-qt so that it does not use my system qt. I can try tomorrow in chroot without qt installed if it's the same.

[pini-gh]

The segfault I experience is definitely not the same as yours. I've spotted precisely where it occurs, but I don't understand it. It occurs at qtopiacore/qt/src/corelib/io/qsettings.cpp:177, when exiting qIsLikelyToBeNfs(). My guess is that the fstatfs() call overrides the stack. gdb shows that the actual function called is fstatfs64(), and it might expect a struct statfs64 parameter, which might be heavier than struct statfs. My understanding stops here :/

Q_AUTOTEST_EXPORT_HELPER bool qIsLikelyToBeNfs(int handle)
{
    struct statfs buf;
    if (fstatfs(handle, &buf) != 0)
        return false;
    return buf.f_type == NFS_SUPER_MAGIC
           || buf.f_type == AUTOFS_SUPER_MAGIC
           || buf.f_type == AUTOFSNG_SUPER_MAGIC;
}

[pini-gh]

Aha... I think I've found it out. That's a side effect of PKG_CONFIGLIBDIR, which is set at native Qt build time as well. Then this build has -I/usr/arm-linux-gnueabi/include_ which causes the wrong size for struct statfs. Need to verify this hypothesis now...

[pini-gh]

Aha... I think I've found it out. That's a side effect of PKG_CONFIG_LIBDIR, which is set at native Qt build time as well. Then this build has -I/usr/arm-linux-gnueabi/include which causes the wrong size for struct statfs. Need to verify this hypothesis now...

Confirmed ! Commit will follow tomorrow.

[radekp]

Great :)

[pini-gh]

Done! It's not perfect yet but it works. Now I'll have to sync with your last changes (pulseaudio). You're moving fast Radek :)

[radekp]

Btw i am still checking if the pulseaudio is good for us. It can pause all apps and let us switch scenarios, so this is perfect for GSM calls. But it might turn out that it has some other problems and we might have to switch back to alsa.

[pini-gh]

Unfortunately, the cross build support for pulseaudio is broken:

• src/libraries/qtopiaaudio/link_test fails with

/usr/lib/gcc/arm-linux-gnueabi/4.4.6/../../../../arm-linux-gnueabi/bin/ld: /tmp/buildd/build-gta04/src/libraries/qtopiaaudio/.obj/qaudioinput_pulse.o: undefined reference to symbol 'pa_bytes_per_second@@PULSE_0'
/usr/lib/gcc/arm-linux-gnueabi/4.4.6/../../../../arm-linux-gnueabi/bin/ld: note: 'pa_bytes_per_second@@PULSE_0' is defined in DSO /usr/arm-linux-gnueabi/lib/libpulse.so.0 so try adding it to the linker command line
/usr/arm-linux-gnueabi/lib/libpulse.so.0: could not read symbols: Invalid operation

• addind -lpulse fails as well with:

/usr/lib/gcc/arm-linux-gnueabi/4.4.6/../../../../arm-linux-gnueabi/bin/ld: warning: libpulsecommon-2.0.so, needed by /usr/lib/gcc/arm-linux-gnueabi/4.4.6/../../../../arm-linux-gnueabi/lib/libpulse-simple.so, not found (try using -rpath or -rpath-link)
/usr/lib/gcc/arm-linux-gnueabi/4.4.6/../../../../arm-linux-gnueabi/lib/libpulse.so: undefined reference to `pa_memblock_get_length'
/usr/lib/gcc/arm-linux-gnueabi/4.4.6/../../../../arm-linux-gnueabi/lib/libpulse.so: undefined reference to `pa_pdispatch_run'
...

• Then adding -lpulsecommon-2.0 doesn't help because libpulsecommon-2.0.so is a pulseaudio internal lib not provided by libpulse-dev (it'a part of libpulse0 only) so it's not pulled out for the target arch by dpkg-cross.

Do you know a way to disable link_test for qtopiaaudio?

[radekp]

Hmm have you tried -lpulse-simple ?

[radekp]

Btw I could cross compile it in sqeeze chroot...

[pini-gh]

Hmm have you tried -lpulse-simple ?

I forgot to mention that -lpulse-simple was already there.

Btw I could cross compile it in sqeeze chroot...

Is libpulse-common-2.0.so installed for the target arch? xapt doesn't install it... I'd have to force libpulse0: in the Build-Depends to have it the Debian way...

[radekp]

Hmm i dont have installed libpulse-common and still i can compile it:

qtmoko-chroot:~/qte/build-gta04$ find /usr/arm-linux-gnueabi/ | grep libpulse-common qtmoko-chroot:~/qte/build-gta04$

[pini-gh]

Hmm i dont have installed libpulse-common and still i can compile it:

Interesting... Will give a closer look at it :/

Thanks for the merge !

[pini-gh]

Hi Radek,

Hmm i dont have installed libpulse-common and still i can compile it:

qtmoko-chroot:~/qte/build-gta04$ find /usr/arm-linux-gnueabi/ | grep libpulse-common qtmoko-chroot:~/qte/build-gta04$

I didn't nociced it at first glance: the correct name is libpulsecommon (no hyphen). Could you please issue this find command again?

Another way is using dpkg to find out which package hold a given path:

dpkg -S libpulsecommon

[radekp]

qtmoko-chroot:~/qte/build-gta04$ find /usr/arm-linux-gnueabi/ | grep libpulsecommon /usr/arm-linux-gnueabi/lib/libpulsecommon-0.9.21.so

[pini-gh]

qtmoko-chroot:~/qte/build-gta04$ find /usr/arm-linux-gnueabi/ | grep libpulsecommon /usr/arm-linux-gnueabi/lib/libpulsecommon-0.9.21.so

OK. It appears that it works for squeeze because libpulsecommon-0.9.21.so is located in the default library path. But for wheezy it has moved into a pulseaudio subdirectory, which prevent it from being properly handled by dpkg-cross :/

[radekp]

Hmm and i am still fighting with pulseaudio. I had working image where all sound was going through pulseaudio. It looked quite good. But then i rebuild the package just with minor change and now qtmoko does not even start with this error message:

glibc detected * qpe: double free or corruption (!prev): 0x0092a248 *

adnd gdb stacktrace shows like inifite number of frames. And then i tried the old install with pulseaudio and it stopped working.

So i wonder how the qtmoko+pulseaudio story will end up. We can always move back to alsa - it's just single change in configure, but then we have to solve the problem with media server not closing the sound card.

And still pulseaudio seems to me the best solution for us. E.g. if you play some movie with mplayer through pulseaudio and someone calls you we can easily pause the mplayer with pasuspender. We could even get rid of mediaserver process in favour of pulseaudio daemon.

[pini-gh]

For sure pulseaudio will provide a higher lever interface. It's worth the effort

In case it ends as the selected solution, I'll have to hack an ugly workaroud into debian/rules, but it shouldn't last after a working true multiarch cross-build solution is finalized.

Using pkg-config to provide pulseaudio build flags might ease my job here. Do you have an idea where to implement that?

[radekp]

Hmm i dont have much experience in this :(

[radekp]

Seems i got the problem with double free or corruption. Under gdb i spotted:

0xb2bec498 in ogg_page_release () from /opt/qtmoko/lib/libvorbisidec.so.1

So i tried to unmount /media/card with my ogg files and it qtmoko started now