On 27/08/10 18:18, Roman Haefeli wrote:
> On Fri, 2010-08-27 at 12:11 +0200, IOhannes zmölnig wrote:
>> On 08/24/2010 12:55 PM, Jonas Smedegaard wrote:
>>> On Mon, Aug 23, 2010 at 09:25:12AM +0200, IOhannes m zmoelnig wrote:
>>> Hmm. Do we then perhaps need to beware of this for helper tools like
>>> lintian and dh_shlibdeps?
>> the other point is of course, whether tools like dh_shlibdeps and
>> dh_strip work correctly.
>> i can only say from experience, that they do.
>> e.g. the binary Gem.pd_linux in the package "gem" is correctly stripped
>> and the package depends on all packages that provide libraries the
>> binary has been dynamically linked to.
>> debian/rules does not extra care of shlibs.
>> so it seems to "just work"
> It seems it's not dh_strip who does the stripping. In the case of the
> gem package it seems to happen already at compile time. After putting an
> unstripped Gem.pd_linux in the temporary directory running dh_strip
> won't touch it all. 

dh_strip doesn't strip anything it doesn't recognize (and it has no way
of being forced into it). Add comments to bug #468333 to ask for support
for this.

In the meantime, you can call

strip --remove-section=.comment --remove-section=.note --strip-unneeded

on each of the pd_linux files.

> Also it seems as if dh_shlibdeps looks only for .so-files. I haven't
> figured out what trickery was used in the gem package to let it find
> also .pd_linux-files. But having a plain .pd-linux file in the temporary
> directory and running dh_shlibdeps doesn't produce anything useful.

You can pass additional arguments for dh_shlibdeps to process:

dh_shlibdeps -- $file1 $file2

Felipe Sateler

pkg-multimedia-maintainers mailing list

Reply via email to