<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html;
      charset=windows-1252">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <p>Hi everybody,</p>
    <p>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>
      - src/server: actual qtopia application<br>
      - src/libraries/qtopia: Collection of libraries that make up the
      bulk of qtopia<br>
      - src/server/phone/dialer: dialer application .....<br>
      However there is something weird going on in how those pieces use
      header files:<br>
      qtopiabase/qtopianamespace.h: #include <QApplication><br>
      declared in<br>
      qtopia/qtopiaapplication.h: class QTOPIA_EXPORT QtopiaApplication
      : public QApplication</p>
    <p>Apparently some 2-step approach is expected here:<br>
      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>
      2. compile source files with generated headers in include path</p>
    <p>But I have no clue how to accomplish that from a simple qmake
      file.<br>
      Any ideas?<br>
    </p>
    <br>
    br<br>
    Josua Mayer<br>
    <div class="moz-cite-prefix">Am 13.10.2017 um 07:58 schrieb H.
      Nikolaus Schaller:<br>
    </div>
    <blockquote type="cite"
      cite="mid:163A71FB-DE16-4658-885C-7E6D988E066A@goldelico.com">
      <meta http-equiv="Content-Type" content="text/html;
        charset=windows-1252">
      Hi,
      <div class=""><br class="">
        <div>
          <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><br class="">
          </div>
          Ok, it is much more complex.</div>
        <div><br class="">
        </div>
        <div>The reason is that the mdeb-qtmoko.rsh script [1]
          debootstraps a fresh Wheezy system</div>
        <div>(using the host architecture) and then does a chroot. To
          fulfill some implicit assumptions</div>
        <div>about the build environment of the QtMoko source tree.</div>
        <div><br class="">
        </div>
        <div>But it does /not/ install ARM cross-toolchains inside :(</div>
        <div><br class="">
        </div>
        <div>So installing Jessie compilers on the host doesn't help
          compiling QtMoko and ends up in</div>
        <div>making elf32-i386 code only...</div>
        <div><br class="">
        </div>
        <div>And it also explains why my attempts to compile qtmoko-pc
          on ARM boards (OMAP5432EVM,</div>
        <div>Letux Cortex 8) failed. There, it does not install a
          toolchain for i386.</div>
        <div><br class="">
        </div>
        <div>Now I have to find a good ARM cross-toolchain for Wheezy.
          For Jessie or Stretch it would</div>
        <div>be easier, but I am quite sure that the QtMoko source tree
          doesn't compile well on Jessie</div>
        <div>or Stretch. And we need a working reference build first,
          comparable to last published</div>
        <div>binary image.</div>
        <div><br class="">
        </div>
        <div>BR,</div>
        <div>Nikolaus</div>
        <div><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>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
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>
  </body>
</html>