Hi Josua,
> Am 12.10.2017 um 13:41 schrieb Josua Mayer <josua.maye...@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.
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@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@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'"?
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
_______________________________________________
Community mailing list
Community@tinkerphones.org
http://lists.goldelico.com/mailman/listinfo.cgi/community
http://www.tinkerphones.org
