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

H. Nikolaus Schaller hns at goldelico.com
Thu Oct 12 14:34:47 CEST 2017

Hi Josua,

> Am 12.10.2017 um 13:41 schrieb Josua Mayer <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>.


Seems to exist and specifyarchicture/build dependent path:


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.

Note that the libamr.so.1 file exists exactly in the library path that is passed:


> 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
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
but not

BTW: I just started to wonder why the qtmoko-neo library is "ELF format: 'elf32-i386'"?

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


> 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,

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.goldelico.com/pipermail/gta04-owner/attachments/20171012/c1843897/attachment.html>

More information about the Gta04-owner mailing list