Hi Josua,
> Am 25.10.2017 um 15:21 schrieb Josua Mayer <josua.maye...@gmail.com>:
>
> Hi everybody,
>
> 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
> qtopia
> - src/server/phone/dialer: dialer application .....
> However there is something weird going on in how those pieces use header
> files:
> qtopiabase/qtopianamespace.h: #include <QApplication>
> declared in
> qtopia/qtopiaapplication.h: class QTOPIA_EXPORT QtopiaApplication : public
> QApplication
>
> 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 here.
> 2. compile source files with generated headers in include path
>
> But I have no clue how to accomplish that from a simple qmake file.
> Any ideas?
>
Well, not very specifically, but maybe my efforts give some clue.
What I have done is to more carefully read the original build instructions.
It turned out that scripts to set up a chroot environment are part of the
root tree. So I wrote another wrapper so that I can run this script inside
a Virtual Box machine with Debian Jessie.
And then it turned out that it is not a simple dpkg-buildpackage despite
debian/rules. One has to do a configure & make & make install step
which magically calls the debian build system.
This configure step might help a little to understand your header generation
problem:
http://git.goldelico.com/?p=gta04-qtmoko.git;a=blob;f=configure;h=bc694ebc2f359bd01ecf75ce9fdf9a12a2ab15f4;hb=refs/heads/master
Now my problem is that the scripts for chroot try to install a g++-4.7
crosstoolchain from emdebian - but the one that is referenced does
not exist. I had found some hints about a data loss at emdebian so
they might not have been able to restore it. Well, there is a source
package for this gcc and I may be able to build it from sources. But haven't
tried yet.
The other problem is with how the chroot is set up. First of all
it creates a new SD card image and mounts that as a loop
device. Then it debootstraps a Wheezy onto this virtual SD card.
And finally it mounts (-bind) this SD root at several locations
before doing the chroot.
This seems to fail with my kernel so that some files from outside
the chroot are not accessible as the scripts expect.
So I still have no progress, but a better understanding that
this number of wrappers (disk image, debootstrap, chroot,
loop device, mount -bind) is too much.
Back to the original problem: I had not expected that there is a
need for a configure-make-install. Since we are fully Debian.
It should even be possible to use apt-source -b - if we have proper
source packages. So it looks as if the build architecture of QtMoko
is upside down...
Maybe it is historical since this is still Squeeze and Wheezy
code and multiarch wasn't complete back then. On Jessie
or Stretch I think it could be much simpler if the debian/rules
are updated.
BR,
Nikolaus
>
> br
> Josua Mayer
> Am 13.10.2017 um 07:58 schrieb H. Nikolaus Schaller:
>> Hi,
>>
>>> Am 12.10.2017 um 19:00 schrieb H. Nikolaus Schaller <h...@goldelico.com
>>> <mailto:h...@goldelico.com>>:
>>>
>>>
>>>> Am 12.10.2017 um 17:08 schrieb Josua Mayer <josua.maye...@gmail.com
>>>> <mailto:josua.maye...@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 [1] 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.
>>
>> BR,
>> Nikolaus
>>
>> [1]:
>> http://git.goldelico.com/?p=gta04-qtmoko.git;a=blob;f=goldelico/mdeb-qtmoko.rsh;h=4f0c230fb980c704c2f0168eb8fc03666540c313;hb=39a9a35c951e0a9d77259ca5dee712b46106cdfb
>>
>> <http://git.goldelico.com/?p=gta04-qtmoko.git;a=blob;f=goldelico/mdeb-qtmoko.rsh;h=4f0c230fb980c704c2f0168eb8fc03666540c313;hb=39a9a35c951e0a9d77259ca5dee712b46106cdfb>
>>
>>
>>
>> _______________________________________________
>> Community mailing list
>> Community@tinkerphones.org <mailto:Community@tinkerphones.org>
>> http://lists.goldelico.com/mailman/listinfo.cgi/community
>> <http://lists.goldelico.com/mailman/listinfo.cgi/community>
>> http://www.tinkerphones.org <http://www.tinkerphones.org/>
> _______________________________________________
> Community mailing list
> Community@tinkerphones.org
> http://lists.goldelico.com/mailman/listinfo.cgi/community
> http://www.tinkerphones.org
_______________________________________________
Community mailing list
Community@tinkerphones.org
http://lists.goldelico.com/mailman/listinfo.cgi/community
http://www.tinkerphones.org
