[Gta04-owner] [Tinkerphones] QtMoko2 again...

Josua Mayer josua.mayer97 at gmail.com
Thu Oct 12 17:08:08 CEST 2017

Hi Nikolaus,

Am 12.10.2017 um 14:34 schrieb H. Nikolaus Schaller:
> Hi Josua,
>> Am 12.10.2017 um 13:41 schrieb Josua Mayer <josua.mayer97 at gmail.com
>> <mailto:josua.mayer97 at gmail.com>>:
>>>>> Hmm, it is the final step before packaging... *not* the linker linking
>>>>> together binaries, so building seems not to fail, just putting it
>>>>> into a package.
>> This is how I understand the purpose of dpkg-shlibdeps:
>> First it finds *all* executables and shared libraries.
> I also think so.
>> For each of those it then checks if the dynamic dependencies are
>> available in system search-paths (and possibly in
>> debian/<install-dir>/<system search-paths>,).
> For that it seems to use ldd.
>> Now of shared libraries are installd in non-standard locations such
>> as /opt/..., we need to pass those to dpkg-shlibdeps with -l<path>.
> Indeed.
> Seems to exist and specifyarchicture/build dependent path:
> http://git.goldelico.com/?p=gta04-qtmoko.git;a=blob;f=debian/rules;h=70a93c3de1f333b1abcd5feaa845bc5579950681;hb=39a9a35c951e0a9d77259ca5dee712b46106cdfb#l199
> dh_shlibdeps -l$(CURDIR)/debian/qtmoko-$(word 1,$(QTMOKO_DEVICES))/opt/qtmoko/lib:/usr/$(DEB_HOST_MULTIARCH)/lib -- $(foreach device,$(QTMOKO_DEVICES),-xqtmoko-$(device))
> That makes the command look like
> 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:
        -- -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
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
> Note that the libamr.so.1 file exists exactly in the library path that
> is passed:
> debian/qtmoko-neo/opt/qtmoko/lib/libamr.so.1
>> Finally, it checks for each dependency, what package is providing
>> that file. This is where the shlibs file comes into play. For example
>> this can be used to handle dependencies on packages that are not
>> installed on the build-host.
> Yes. But here, the problematic libs are listed side-by-side with
> unproblematic ones.
>> Now I know of two reasons that can lead to above error:
>> a) library file is not in one of the paths where dpkg-shlibdeps searches
> That is what I thought - until I found that it does not complain about
> other libs in the same directory.
> Or there is some magic to copy files around which fails here.
>> b) library file has been skipped for a reason. That reason might
>> appear hundreds of lines earlier in the build log.
> Ok. So it might exist but missing somewhere in the dependency graph.
> There is one thing that is not exactly clear to me:
> how the build-gta04, build-neo, and build-pc things relate.
> Although the error comes when qtmoko-neo is being built - at least I
> assume that from the error message
> dpkg-shlibdeps: error: couldn't find library libamr.so.1 needed by
> debian/qtmoko-neo/opt/qtmoko/plugins/codecs/libamrrecordplugin.so (ELF
> format: 'elf32-i386'; RPATH: '')
> there is a small difference in the three subdirectories. I mean this:
> root at debian:/qtmoko-wheezy-build/src# find . -name libamr.so.1 -o
> -name libqtopiabase.so.4
> ./build-neo/image/lib/libamr.so.1
> ./build-neo/image/lib/libqtopiabase.so.4
> ./build-neo/sdk/lib/libamr.so.1
> ./build-neo/sdk/lib/libqtopiabase.so.4
> ./build-gta04/image/lib/libqtopiabase.so.4
> ./build-gta04/sdk/lib/libqtopiabase.so.4
> ./qtmoko-master/debian/qtmoko-pc/opt/qtmoko/lib/libqtopiabase.so.4
> ./qtmoko-master/debian/qtmoko-neo/opt/qtmoko/lib/libamr.so.1
> ./qtmoko-master/debian/qtmoko-neo/opt/qtmoko/lib/libqtopiabase.so.4
> ./qtmoko-master/debian/tmp-pc/opt/qtmoko/lib/libqtopiabase.so.4
> ./qtmoko-master/debian/tmp-gta04/opt/qtmoko/lib/libqtopiabase.so.4
> ./qtmoko-master/debian/tmp-neo/opt/qtmoko/lib/libamr.so.1
> ./qtmoko-master/debian/tmp-neo/opt/qtmoko/lib/libqtopiabase.so.4
> ./qtmoko-master/debian/qtmoko-gta04/opt/qtmoko/lib/libqtopiabase.so.4
> ./build-pc/image/lib/libqtopiabase.so.4
> ./build-pc/sdk/lib/libqtopiabase.so.4
> root at debian:/qtmoko-wheezy-build/src#
> As we can see there is a libqtopiabase.so.4 in all three.
> But there is no libamr.so.1 in build-pc and build-gta04.
> So we only have
> debian/qtmoko-neo/opt/qtmoko/lib/libamr.so.1
> but not
> debian/qtmoko-gta04/opt/qtmoko/lib/libamr.so.1
> debian/qtmoko-pc/opt/qtmoko/lib/libamr.so.1
> BTW: I just started to wonder why the qtmoko-neo library is "ELF
> format: 'elf32-i386'"?
Looks like it was an x86 build.
> So there could be some mixup with multiple architectures,
> cross-compiler selection and
> maybe all libamr.so.1 objects are overwritten by the next
> architecture? Maybe some
> architecture dependent path setup gets wrong.
>>      Maybe someone could submit the huge build log?
> I have uploaded the last complete build log (incl. chroot stuff) to
> http://download.goldelico.com/qtmoko2/files/
>> However it might be necessary to add
>>      export DH_VERBOSE=1
>>      near the top of debian/rules.
> I'll try on next build...
> BR and thanks,
> Nikolaus
Josua Mayer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.goldelico.com/pipermail/gta04-owner/attachments/20171012/a0af99b7/attachment-0001.html>

More information about the Gta04-owner mailing list