On 05/19/2016 05:53 PM, Jakub Wilk wrote:
> * Jens Reyer <jre.wine...@gmail.com>, 2016-05-19, 16:57:
>> First off, I'm not sure about every single dependency if it is needed
>> at all.
>
> Quick grep over the *.dll.so indeed shows that they use a bunch of
> libraries you mentioned:
[...]
> I guess a better method of obtaining the list of used shared libraries
> is to grep for "SONAME_" in include/config.h (after it was created by
> the configure script).
>
> Once you have the list of needed shlibs, the simplest way to compute
> package dependency is to create an ELF that depends on all of them, and
> then use dpkg-shlibdeps against it.
>
> You can steal the idea of how to create such ELF here:
> https://bitbucket.org/jwilk/python-dctypes/src/default/dctypes2elf
Thanks a lot Jakub and Gianfranco!
I think I have it working now in wine to automatically generate a
list of runtime dependencies. I based it on Jakub's suggestions,
however I didn't go for creating a "dependency binary".
For one I did get results this way, but unfortunately I neither
really know python nor perl which is usually used in wine
packaging, in order to cleanly implement it there. Generally more
relevant however, since I probably found a Makefile/shell
solution, I'd like to keep it as simple as possible.
I chose to (as suggested) first check for all sonames in
include/config.h after configure. This gives similar results as
grep'ing for *.so (and a lot more than for *.dll.so). The
differences are only for shlibs, which are not relevant here.
Then (instead of creating a binary linking to the required
libraries and running dpkg-shlibdeps on this) I replicate things
from dpkg-shlibdeps(1) to identify the library package names for
these sonames:
- first find the library file on the system (looking in some
hardcoded directories),
- then use "dpkg -S library-file" to lookup the package providing
the library.
I put these library names in a custom substvar
${dlopen:Recommends}, and pass it on with dh_gencontrol. Done.
I'd like to hear your opinion on this, for now my own thoughts:
- As long as there are no specific symbols to work with, we don't
know if we'd need a version constraint (I think this was
Gianfranco's point). But since I'm only looking for the sonames,
we can't profit from using a sophisticated tool as
dpkg-shlibdeps.
Anyway, this is superior to not having these dependencies at all,
or to hardcoding them (we still can manually add e.g. a version
constraint if necessary).
- I look for the soname files in a hardcoded list of dirs (/lib,
/usr/lib, /lib/DEB_HOST_MULTIARCH and
/usr/lib/DEB_HOST_MULTIARCH).
dpkg-shlibdeps would be more flexible here, but we just need it
to work for us. Are there any problems with that, e.g. for other
ports (kfreebsd, hurd) or anything else?
For reference, this is my implementation:
d/rules:
# additional dlopen runtime dependencies
sonames=$(shell grep "^\#define SONAME_" include/config.h | cut -d\" -f2)
paths=/usr /usr/lib /lib/$(shell dpkg-architecture -qDEB_HOST_MULTIARCH)
/usr/lib/$(shell dpkg-architecture -qDEB_HOST_MULTIARCH)
dlopenRecommends=$(shell \
for soname in $(sonames); do \
for path in $(paths); do \
file=$$(echo $$path/$$soname | sed "s|//|/|g"); \
[ -f $$file ] && dpkg -S $$file | cut -d: -f1 | sed "s/\\(.*\\)
*/\\1,/" && break || true; \
done; \
done)
override_dh_gencontrol:
dh_gencontrol -- \
-Vdlopen:Recommends="$(dlopenRecommends)"
d/control:
libwine Recommends: ${dlopen:Recommends},
Thanks again for the valuable input!
Greets
jre
