Felix Lechner <felix.lechner@lease-up.com> writes:
> Do you have the output of 'readelf --all --wide' [1] for one of those
> binaries?
The elf library binaries delivered by the package actually look fine.
Digging further, it appears the problem cases are all in guile code,
where the function dynamic-link is handed a token like 'libglib-2.0':
(define libglib (dynamic-link "libglib-2.0"))
This guile code gets "compiled" on the first invocation of the
application and cached in ~/.cache/guile. The problem is that at
runtime, that function call results in an attempt to load
'libglib-2.0.so' which fails if the -dev package isn't installed.
I'm fixing those with Makefile.am changes like:
-LIBGLIB=libglib-2.0
+LIBGLIB := $(shell /sbin/ldconfig -p | awk '/libglib-2.0.so\./ { print $$1 }')
That changes the guile code to look like:
(define libglib (dynamic-link "libglib-2.0.so.0"))
which works as desired at runtime, since that symlink is provided by the
binary library package.
So .. I'm not sure how good the return on investment of trying to add a
test for this in lintian would be. Talking to upstream about it, the
approach I'm using in Makefile.am seems credible and they make just take
that in. There's no indication the dynamic-link function in guile is
going to get any "smarter", so Makefile.am is probably the right place
to fix the problem.
> Your condition involves sonames that I believe are customarily
> provided by links in '-dev' installables instead of regular shared
> library packages.
Exactly.
> What do you think, please? Thanks!
I don't know if lintian already tries to parse any scheme source. If
not, just close this as I don't think it's worth chasing. If it does,
we could perhaps add a test for the dynamic-link function being handed a
token without '.so.0' in it, or something?
Bdale
Attachment:
signature.asc
Description: PGP signature