<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Hi Josua,<div class=""><br class=""><div><blockquote type="cite" class=""><div class="">Am 25.10.2017 um 15:21 schrieb Josua Mayer <<a href="mailto:josua.mayer97@gmail.com" class="">josua.mayer97@gmail.com</a>>:</div><br class="Apple-interchange-newline"><div class="">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252" class="">
<div text="#000000" bgcolor="#FFFFFF" class=""><p class="">Hi everybody,</p><p class="">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:<br class="">
- src/server: actual qtopia application<br class="">
- src/libraries/qtopia: Collection of libraries that make up the
bulk of qtopia<br class="">
- src/server/phone/dialer: dialer application .....<br class="">
However there is something weird going on in how those pieces use
header files:<br class="">
qtopiabase/qtopianamespace.h: #include <QApplication><br class="">
declared in<br class="">
qtopia/qtopiaapplication.h: class QTOPIA_EXPORT QtopiaApplication
: public QApplication</p><p class="">Apparently some 2-step approach is expected here:<br class="">
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 here.<br class="">
2. compile source files with generated headers in include path</p><p class="">But I have no clue how to accomplish that from a simple qmake
file.<br class="">
Any ideas?<br class=""></p></div></div></blockquote><div><br class=""></div>Well, not very specifically, but maybe my efforts give some clue.</div><div><br class=""></div><div>What I have done is to more carefully read the original build instructions.</div><div><br class=""></div><div>It turned out that scripts to set up a chroot environment are part of the</div><div>root tree. So I wrote another wrapper so that I can run this script inside</div><div>a Virtual Box machine with Debian Jessie.</div><div><br class=""></div><div>And then it turned out that it is not a simple dpkg-buildpackage despite</div><div>debian/rules. One has to do a configure & make & make install step</div><div>which magically calls the debian build system.</div><div><br class=""></div><div>This configure step might help a little to understand your header generation</div><div>problem:</div><div><br class=""></div><div><span class="Apple-tab-span" style="white-space:pre"> </span><a href="http://git.goldelico.com/?p=gta04-qtmoko.git;a=blob;f=configure;h=bc694ebc2f359bd01ecf75ce9fdf9a12a2ab15f4;hb=refs/heads/master" class="">http://git.goldelico.com/?p=gta04-qtmoko.git;a=blob;f=configure;h=bc694ebc2f359bd01ecf75ce9fdf9a12a2ab15f4;hb=refs/heads/master</a></div><div><br class=""></div><div>Now my problem is that the scripts for chroot try to install a g++-4.7</div><div>crosstoolchain from emdebian - but the one that is referenced does</div><div>not exist. I had found some hints about a data loss at emdebian so</div><div>they might not have been able to restore it. Well, there is a source</div><div>package for this gcc and I may be able to build it from sources. But haven't</div><div>tried yet.</div><div><br class=""></div><div>The other problem is with how the chroot is set up. First of all</div><div>it creates a new SD card image and mounts that as a loop</div><div>device. Then it debootstraps a Wheezy onto this virtual SD card.</div><div>And finally it mounts (-bind) this SD root at several locations</div><div>before doing the chroot.</div><div><br class=""></div><div>This seems to fail with my kernel so that some files from outside</div><div>the chroot are not accessible as the scripts expect.</div><div><br class=""></div><div>So I still have no progress, but a better understanding that</div><div>this number of wrappers (disk image, debootstrap, chroot,</div><div>loop device, mount -bind) is too much.</div><div><br class=""></div><div>Back to the original problem: I had not expected that there is a</div><div>need for a configure-make-install. Since we are fully Debian.</div><div><br class=""></div><div>It should even be possible to use apt-source -b - if we have proper</div><div>source packages. So it looks as if the build architecture of QtMoko</div><div>is upside down...</div><div><br class=""></div><div>Maybe it is historical since this is still Squeeze and Wheezy</div><div>code and multiarch wasn't complete back then. On Jessie</div><div>or Stretch I think it could be much simpler if the debian/rules</div><div>are updated.</div><div><br class=""></div><div>BR,</div><div>Nikolaus<br class=""><blockquote type="cite" class=""><div class=""><div text="#000000" bgcolor="#FFFFFF" class=""><p class="">
</p>
<br class="">
br<br class="">
Josua Mayer<br class="">
<div class="moz-cite-prefix">Am 13.10.2017 um 07:58 schrieb H.
Nikolaus Schaller:<br class="">
</div>
<blockquote type="cite" cite="mid:163A71FB-DE16-4658-885C-7E6D988E066A@goldelico.com" class="">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252" class="">
Hi,
<div class=""><br class="">
<div class="">
<blockquote type="cite" class="">
<div class="">Am 12.10.2017 um 19:00 schrieb H. Nikolaus
Schaller <<a href="mailto:hns@goldelico.com" class="" moz-do-not-send="true">hns@goldelico.com</a>>:</div>
<br class="Apple-interchange-newline">
<div class="">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252" class="">
<div style="word-wrap: break-word; -webkit-nbsp-mode:
space; -webkit-line-break: after-white-space;" class=""><br class="">
<div class="">
<blockquote type="cite" class="">
<div class="">Am 12.10.2017 um 17:08 schrieb Josua
Mayer <<a href="mailto:josua.mayer97@gmail.com" class="" moz-do-not-send="true">josua.mayer97@gmail.com</a>>:</div>
<br class="Apple-interchange-newline">
<div class="">
<meta http-equiv="Content-Type" content="text/html; charset=windows-1252" class="">
<div text="#000000" bgcolor="#FFFFFF" class="">
<blockquote type="cite" cite="mid:E3B55DBB-F264-4BB6-9C06-37CCCEF85830@goldelico.com" class="">
<div class="">
<div class="">
<div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>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 ...</div>
<div class=""><br class="">
</div>
<div class="">(especially the -x arguments
and the debian/qrmoko-*/opt/qtmoko
things.</div>
</div>
</div>
</blockquote>
So error-log.txt line 155044 reads:<br class="">
dh_shlibdeps
-l/src/qtmoko-master/debian/qtmoko-gta04/opt/qtmoko/lib:/usr/i386-linux-gnu/lib
\<br class="">
-- -xqtmoko-gta04 -xqtmoko-neo
-xqtmoko-pc<br class="">
Notice how it only passes debian/qtmoko-gta04 as
search-path to shlibdeps!<br class="">
I believe this is what we need to fix: Either
add all build-flavours to the search path,<br class="">
*or* call shlibdeps individually for every
package (qtmok-neo,qtmoko-pc,...).<br class="">
The latter would look similar to this:<br class="">
dh_shlibdeps -l<span class="pl-s">$(<span class="pl-c1">CURDIR</span>)</span>/debian/qtmoko-gta04/opt/qtmoko/lib
-pqtmoko-gta04<br class="">
For a full example, see this rules file where I
made heavy use of this feature:<br class="">
<a class="moz-txt-link-freetext" href="https://github.com/mxOBS/deb-pkg_gpu-viv-bin/blob/stable/debian/rules#L68" moz-do-not-send="true">https://github.com/mxOBS/deb-pkg_gpu-viv-bin/blob/stable/debian/rules#L68</a><br class="">
</div>
</div>
</blockquote>
<div class=""><br class="">
</div>
Ah, yes. Looks reasonable and should not harm...</div>
<div class=""><br class="">
<blockquote type="cite" class="">
<div class="">
<div text="#000000" bgcolor="#FFFFFF" class="">
<blockquote type="cite" cite="mid:E3B55DBB-F264-4BB6-9C06-37CCCEF85830@goldelico.com" class="">
<div class="">
<div class=""> </div>
</div>
</blockquote>
<blockquote type="cite" cite="mid:E3B55DBB-F264-4BB6-9C06-37CCCEF85830@goldelico.com" class="">
<div class="">
<div class=""><br class="">
</div>
<div class="">BTW: I just started to wonder
why the qtmoko-neo library is "ELF format:
'elf32-i386'"?</div>
</div>
</blockquote>
Looks like it was an x86 build.<br class="">
</div>
</div>
</blockquote>
<br class="">
</div>
<div class="">It looks as if my cross-compiler is not
properly called/found. Previously I did try to compile</div>
<div class="">natively on ARM and just recently switched
to the i386 system in a VirtualBox. So it</div>
<div class="">may simply be not in the PATH...</div>
</div>
</div>
</blockquote>
<div class=""><br class="">
</div>
Ok, it is much more complex.</div>
<div class=""><br class="">
</div>
<div class="">The reason is that the mdeb-qtmoko.rsh script [1]
debootstraps a fresh Wheezy system</div>
<div class="">(using the host architecture) and then does a chroot. To
fulfill some implicit assumptions</div>
<div class="">about the build environment of the QtMoko source tree.</div>
<div class=""><br class="">
</div>
<div class="">But it does /not/ install ARM cross-toolchains inside :(</div>
<div class=""><br class="">
</div>
<div class="">So installing Jessie compilers on the host doesn't help
compiling QtMoko and ends up in</div>
<div class="">making elf32-i386 code only...</div>
<div class=""><br class="">
</div>
<div class="">And it also explains why my attempts to compile qtmoko-pc
on ARM boards (OMAP5432EVM,</div>
<div class="">Letux Cortex 8) failed. There, it does not install a
toolchain for i386.</div>
<div class=""><br class="">
</div>
<div class="">Now I have to find a good ARM cross-toolchain for Wheezy.
For Jessie or Stretch it would</div>
<div class="">be easier, but I am quite sure that the QtMoko source tree
doesn't compile well on Jessie</div>
<div class="">or Stretch. And we need a working reference build first,
comparable to last published</div>
<div class="">binary image.</div>
<div class=""><br class="">
</div>
<div class="">BR,</div>
<div class="">Nikolaus</div>
<div class=""><br class="">
</div>
<div class="">[1]: <a href="http://git.goldelico.com/?p=gta04-qtmoko.git;a=blob;f=goldelico/mdeb-qtmoko.rsh;h=4f0c230fb980c704c2f0168eb8fc03666540c313;hb=39a9a35c951e0a9d77259ca5dee712b46106cdfb" class="" moz-do-not-send="true">http://git.goldelico.com/?p=gta04-qtmoko.git;a=blob;f=goldelico/mdeb-qtmoko.rsh;h=4f0c230fb980c704c2f0168eb8fc03666540c313;hb=39a9a35c951e0a9d77259ca5dee712b46106cdfb</a><br class="">
</div>
<div class=""><br class="">
</div>
</div>
<br class="">
<fieldset class="mimeAttachmentHeader"></fieldset>
<br class="">
<pre wrap="" class="">_______________________________________________
Community mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Community@tinkerphones.org">Community@tinkerphones.org</a>
<a class="moz-txt-link-freetext" href="http://lists.goldelico.com/mailman/listinfo.cgi/community">http://lists.goldelico.com/mailman/listinfo.cgi/community</a>
<a class="moz-txt-link-freetext" href="http://www.tinkerphones.org/">http://www.tinkerphones.org</a></pre>
</blockquote>
<br class="">
</div>
_______________________________________________<br class="">Community mailing list<br class=""><a href="mailto:Community@tinkerphones.org" class="">Community@tinkerphones.org</a><br class="">http://lists.goldelico.com/mailman/listinfo.cgi/community<br class="">http://www.tinkerphones.org</div></blockquote></div><br class=""></div></body></html>