On Mon, Aug 14, 2017 at 02:55:57PM -0600, Stephen Dennis wrote: > Ah. missed the compat level because I changed the it to version 10 in the > debian/control file. Next upload will have debian/compat of 10, and > debian/control has "Build-Depends: debhelper (>= 10.0.0), binutils (>= > 2.28.0), autotools-dev (>= 20161112.1)" Are you sure you need autotools-dev? By the way, binutils (>= 2.28.0) is wrong, as 2.28-1 is not >= 2.28.0.
> So now to talk about the dpkg-shlibdeps warnings. The Debian package > installs the binaries (libmux.so and others) > under usr/lib/tinymux/game/bin, and then for a specific game, one runs > tinymux-install script to install a symbolic link into the current > directory. The install scripts creates a minimal game tree from which to > start a game. So, the server itself never runs directly from the > /usr/lib/tinymux/game/bin directory. That's why it works despite these > warnings. That doesn't matter, as the libs are not searched for in the current dir/the dir of the dependent binary. > But, I agree that suppressing or fixing these warning is a good thing > except that nothing I Google and no man pages I read describe how to > actually go about doing this. dh_shlibdeps(1)/dpkg-shlibdeps(1) "It tells dpkg-shlibdeps (via its -l parameter), to look for private package libraries in the specified directory" > dh_makeshlibs does run but it isn't picking > up the location where libmux.so is placed. The man page for dh_shlibdeps > describes this exact scenario and suggests to run dh_makeshlibs first as > the obvious solution, but that is already happening and it doesn't work. No, it describes a scenario with a public shared lib in a separate package. Your problem is caused by a private shared lib in a private path. > Solutions point to using override_dh_shlibdeps, but then, I need to pass it > all the right arguments and I think the problem is really dh_makeshlibs. I don't think so. -- WBR, wRAR
signature.asc
Description: PGP signature
