[Tinkerphones] [Gta04-owner] QtMoko2 again...
H. Nikolaus Schaller
hns at goldelico.com
Fri Oct 13 07:58:50 CEST 2017
> Am 12.10.2017 um 19:00 schrieb H. Nikolaus Schaller <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/libqgenericbearer.so 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:
>> dh_shlibdeps -l/src/qtmoko-master/debian/qtmoko-gta04/opt/qtmoko/lib:/usr/i386-linux-gnu/lib \
>> -- -xqtmoko-gta04 -xqtmoko-neo -xqtmoko-pc
>> Notice how it only passes debian/qtmoko-gta04 as search-path to shlibdeps!
>> 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 (qtmok-neo,qtmoko-pc,...).
>> The latter would look similar to this:
>> dh_shlibdeps -l$(CURDIR)/debian/qtmoko-gta04/opt/qtmoko/lib -pqtmoko-gta04
>> For a full example, see this rules file where I made heavy use of this feature:
>> https://github.com/mxOBS/deb-pkg_gpu-viv-bin/blob/stable/debian/rules#L68 <https://github.com/mxOBS/deb-pkg_gpu-viv-bin/blob/stable/debian/rules#L68>
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Community