On Sat, 13 Feb 2010 at 14:08:07 -0800, Steve Langasek wrote: > FWIW, it was an unintended consequence of the wording of the policy change > that static libs and .so symlinks are permitted in the multiarch dirs at > this point
As Goswin pointed out in an earlier thread, in the general case (libraries
that load plugins) much smaller patches to upstream code tend to be involved
in changing ${libdir}, as I did here, rather than trying to move the runtime
library, plugins, etc. independently.
I've started a proof-of-concept patch for Mesa (which has DRI drivers as
plugins) as an example of a library that loads plugins, and I see you've done
some work on a multiarch branch for pam.
(Would you mind if I filed a wishlist bug on pam referencing your branch,
by the way? I nearly started reimplementing it before I realised you'd
got there first...)
> We don't really want extra -L options passed to the build for every library
> that's installed to the multiarch lib dir.
A portable pkg-config file will always have these -L options (because they'd
be needed if the library was in a non-standard location), and rely on
pkg-config to filter them out. You're right that pkg-config will need patching
to do this for the multiarch directories too.
However, that doesn't seem to be fatal:
> Has anyone verified that these extra -L options don't cause libtool to add
> wrong rpaths to resulting binaries?
I hadn't, but it appears to be OK both with and without libtool. I'll verify
this by preparing a multiarch patch for something that has non-trivial reverse
dependencies.
> Has anyone checked that gdb will succeed in finding debug symbols via the
> multiarch paths? (I guess gdb handles these generically by prepending
> /usr/lib/debug to the real object path, but probably should be
> double-checked anyway)
Seems to work fine, here's a gdb session:
> s...@reptile% gdb --args /usr/bin/gfsplit hello.c
> ...
> Reading symbols from /usr/bin/gfsplit...Reading symbols from
> /usr/lib/debug/usr/bin/gfsplit...done.
> (no debugging symbols found)...done.
> (gdb) break gfshare_ctx_init_enc
> Breakpoint 1 at 0x8048af0
> (gdb) run
> Starting program: /usr/bin/gfsplit hello.c
>
> Breakpoint 1, gfshare_ctx_init_enc (sharenrs=0x804b008 "\266\037\210\315)",
> sharecount=5, threshold=3 '\003', size=29) at src/libgfshare.c:107
The warning about (no debugging symbols found) concerns me a bit, but
the stack frame that's in the library does seem to have full debug
information, and when I rename
/usr/lib/debug/usr/lib/i486-linux-gnu/libgfshare.so.1.0.3 (only) out of the
way and try again, I get a backtrace with no line number or argument
information. So, gdb must have been finding the debug symbols, and the message
is hopefully only cosmetic.
Thanks for the feedback,
Simon
signature.asc
Description: Digital signature
