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:
> smcv@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
Attachment:
signature.asc
Description: Digital signature