[Tinkerphones] [Gta04-owner] QtMoko2 again...
josua.mayer97 at gmail.com
Wed Oct 25 15:21:29 CEST 2017
I had a look at the original plan of building individual pieces against
a recebt system-wide Qt. So far I believe I've identified these components:
- src/server: actual qtopia application
- src/libraries/qtopia: Collection of libraries that make up the bulk of
- src/server/phone/dialer: dialer application .....
However there is something weird going on in how those pieces use header
qtopiabase/qtopianamespace.h: #include <QApplication>
qtopia/qtopiaapplication.h: class QTOPIA_EXPORT QtopiaApplication :
Apparently some 2-step approach is expected here:
1. process header files to generate a c++-style header for every class,
called <class>, e.g. QApplication. I guess QTOPIA_EXPORT is the keyword
2. compile source files with generated headers in include path
But I have no clue how to accomplish that from a simple qmake file.
Am 13.10.2017 um 07:58 schrieb H. Nikolaus Schaller:
>> Am 12.10.2017 um 19:00 schrieb H. Nikolaus Schaller
>> <hns at goldelico.com <mailto:hns at goldelico.com>>:
>>> Am 12.10.2017 um 17:08 schrieb Josua Mayer <josua.mayer97 at gmail.com
>>> <mailto:josua.mayer97 at gmail.com>>:
>>>> dpkg-shlibdeps -Tdebian/qtmoko-neo.substvars -xqtmoko-gta04
>>>> -xqtmoko-neo -xqtmoko-pc
>>>> debian/qtmoko-neo/opt/qtmoko/qt_plugins/bearer/libqconnmanbearer.so ...
>>>> (especially the -x arguments and the debian/qrmoko-*/opt/qtmoko things.
>>> So error-log.txt line 155044 reads:
>>> -- -xqtmoko-gta04 -xqtmoko-neo -xqtmoko-pc
>>> Notice how it only passes debian/qtmoko-gta04 as search-path to
>>> I believe this is what we need to fix: Either add all build-flavours
>>> to the search path,
>>> *or* call shlibdeps individually for every package
>>> The latter would look similar to this:
>>> dh_shlibdeps -l$(CURDIR)/debian/qtmoko-gta04/opt/qtmoko/lib
>>> For a full example, see this rules file where I made heavy use of
>>> this feature:
>> Ah, yes. Looks reasonable and should not harm...
>>>> BTW: I just started to wonder why the qtmoko-neo library is "ELF
>>>> format: 'elf32-i386'"?
>>> Looks like it was an x86 build.
>> It looks as if my cross-compiler is not properly called/found.
>> Previously I did try to compile
>> natively on ARM and just recently switched to the i386 system in a
>> VirtualBox. So it
>> may simply be not in the PATH...
> Ok, it is much more complex.
> The reason is that the mdeb-qtmoko.rsh script  debootstraps a fresh
> Wheezy system
> (using the host architecture) and then does a chroot. To fulfill some
> implicit assumptions
> about the build environment of the QtMoko source tree.
> But it does /not/ install ARM cross-toolchains inside :(
> So installing Jessie compilers on the host doesn't help compiling
> QtMoko and ends up in
> making elf32-i386 code only...
> And it also explains why my attempts to compile qtmoko-pc on ARM
> boards (OMAP5432EVM,
> Letux Cortex 8) failed. There, it does not install a toolchain for i386.
> Now I have to find a good ARM cross-toolchain for Wheezy. For Jessie
> or Stretch it would
> be easier, but I am quite sure that the QtMoko source tree doesn't
> compile well on Jessie
> or Stretch. And we need a working reference build first, comparable to
> last published
> binary image.
> Community mailing list
> Community at tinkerphones.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Community